Only Share Context Information Between UIs
Context
Microservices are being adopted. There are multiple user interface applications for the application that users can change between.
Problem
- The user interfaces applications need to share data among them to present the user a cohesive user experience.
- E.g., the user should only sign in once and not in every user interface application.
Solution
Share context information between user interface (UI) applications, and only context information.
Reducing communication to a minimum between UI applications supports a low coupling. As an implication, only share ids necessary to understand the user's context. The UI applications can fetch associated entities themselves, potentially in their view on the object.
Classical ways to share state between UI applications in the browser are:
- global objects with a publish-subscribe-like API,
- cookies,
- session and local storage.
Maturity
Proposed, evaluation needed.
Sources of Evidence
L14:
- Verticals at otto.de
- no HTTP sessions, shared caches or similar.
- Minimal client-side state is shared between different systems
- cookies / local storage
- common understanding who is accessing the shop
Interview B:
- Security: get token once in UI / via Gateway
- always send token wit requests
- handling of refresh token starts in UI
Interview E:
- Context: shared authentication with multiple UIs
- Need to communicate token so that all can use the same
- Easier if token is in cookie
- Every microfrontend needs to come from the same origin / be bundled by same origin
- need to secure against cross-site-request forgery attacks
- Context: communication between UIs
- usually exchange context information
- which customer is it about, which user group, which user
- can be usually counted on one hand
- send whole entities or ids between microfrontends?
- ids and then get entities from backend to keep coupling low
- how communication between microfrontends?
- If shell solution where frontends are embedded => simple bus solution, e.g., shared object with send and subscribe methods
- potentially a litte more logic due to lazy loading => cache to get the whole context
- If hyperlink solution => shared worker, or session/local storage
- solution often seen: over backend: send around URLs or server-sent events / web-sockets
- usually URL parameters suffice; worst case: refresh if I see something outdated
- If shell solution where frontends are embedded => simple bus solution, e.g., shared object with send and subscribe methods
- usually exchange context information