Authenticated intermediary application
Service portal for professional intermediaries
An authenticated workspace where professional intermediaries move between public-service operations through shared navigation and permission-aware views.
The application supports professional users who work across related public-service operations. It provides a shared authenticated workspace with consistent navigation, while individual features retain the data and behavior needed for their own tasks.
01 / The application
A coherent workspace for related operations
The application surrounds its service views with shared headers, footers, breadcrumbs, side navigation and tabs. Those elements help users understand where they are and move between related operations.
The Angular frontend uses standalone components for feature composition, Signals for navigation state and the Router for access checks and view data.
02 / Route responsibilities
Separate access checks, route data and HTTP policies
Authenticated workflows can scatter access checks, data loading and request policies across page components. A view then has to reconstruct its own prerequisites and may show incomplete or inconsistent navigation while loading.
I organized the application around standalone Angular components and clear route responsibilities: guards for access decisions, resolvers for required view data and interceptors for shared HTTP behavior. I kept the shell responsible for layout and navigation rather than feature operations.
Resolvers can delay navigation if they fetch too much. Guards cannot replace server authorization, and interceptors become difficult to follow if they accumulate feature-specific business rules.
03 / Reactive navigation
Derive breadcrumbs and tabs from shared state
Breadcrumbs, side navigation and tabs can each maintain a separate idea of the current page. Updating them independently makes stale selections and inconsistent labels more likely after route or permission changes.
I used Signals for synchronous navigation state and derived breadcrumbs, side navigation and tabs from route and application data. I retained RxJS for asynchronous workflows instead of asking Signals to handle every kind of state.
Signals suit synchronous UI relationships; RxJS remains useful for request cancellation and asynchronous coordination. Keeping feature data outside the shared navigation state prevents the shell from taking on unrelated responsibilities.
04 / Keyboard interaction
Keep navigation usable from the keyboard
A correctly selected tab is insufficient if focus, semantics or browser history do not make the current destination understandable. Reimplementing navigation behavior in each feature repeats those integration risks.
I worked on reusable breadcrumbs, sidebars and tabs, keeping their selected state tied to routing. This gave features a consistent navigation model while leaving their labels, destinations and access requirements explicit.
Route changes still need to handle loading and focus deliberately. A reusable tab component helps with consistent interaction, but each feature must supply the correct labels, destinations and selected state.
Evidence & further reading