Deep Linking with nested Master-Detail views - is MDL as RL the right approach?

Flow
1

Hi everyone,

I’m working on a platform where my domain objects form a cyclic graph, not a tree:

  • A Game has many Servers
  • A Server belongs to one Game and one User
  • A User has many Servers

In a Master-Detail UI, the user might naturally navigate like this:

Game > Server > User > Server > Game > ...

Or more abstractly: A > B > C > D > E > F > B > A

The problem with pure URL-based routing:

If I encode every navigation step into the URL, I end up with something like:

/games/1/servers/5/users/3/servers/5/games/1

That’s not just ugly, but it also breaks down semantically, because the URL is no longer a resource path, it’s a navigation history. And it could theoretically grow unbounded.

On the other hand, if I collapse the URL to only the “current” object (e.g. always just /servers/5), I lose the navigation context and the back button becomes useless and I can’t reconstruct “how did I get here”.

What I’m wondering:

Is there a known pattern in Vaadin (or the broader community) for this kind of situation? Specifically:

  • Does Vaadin have any built-in support for in-memory navigation stacks / breadcrumb history that stays separate from the URL?
  • Is the right approach to keep URLs clean (just the current object) and maintain a client- or session-side navigation stack manually?
  • Or is there a smarter URL strategy that handles cycles gracefully without blowing up the path?

Matrix42 (a enterprise ticketing tool) seems to handle this with in-memory navigation rather than URL-based routing, but that sacrifices deep linking entirely. Is there a middle ground?

Curious how others have tackled this, especially in more complex domain models where object relationships aren’t strictly hierarchical.

Thanks!

2

Have you tried to solve this with query parameters ?
Due to their optional nature, it’s maybe a good fit ?

Dominik

3

Thanks Dominik!
Could you maybe show a small example of what you have in mind? I’m not 100% sure how you’d handle the full navigation path (e.g. A > B > C > B > A) with query parameters…

4

I’d suggest ignoring the RouterLayout aspect of MasterDetailLayout and instead treat it as a single view that looks at the rest of the URL to either render an empty detail panel or to render some specific content in it. This becomes even more natural starting from Vaadin 25.1 where you can use signals to control what’s rendered.

I also agree that the URL should be a representation of the resource and not the journey that took you to that resource. The browser already keeps track of the history so that back and forward buttons work as expected as long as you’re triggering state changes in a way that updates the URL accordingly.

What remains then is only that you might want to still show the journey in the UI. For this case, you’d have to manually maintain your own in-memory record of the navigation history since the browser’s history isn’t directly available to server-side logic.