Closed thewilkybarkid closed 4 years ago
Couple of different paths for this:
Don't use sessions
Use a JWT instead, so all the information is stored in a cookie.
Advantages
Disadvantages
Use a session-service
Have a backend service for sessions, and the cookie is just a token.
Advantages
Disadvantages
Combine the two
Use a JWT for general data, regular sessions for more secure/larger requirements.
Advantages
Disadvantages
On one hand if we go API-first it means the underlying APIs have to know if you are logged in, not just the frontends (all public/private caching caveats apply).
Lest we create a single point of failure that all dependencies converge to, this looks more like a token or other signed information that travels in API calls, rather than a shared session in the usual web application sense (which is identical to a shared database).
On one hand if we go API-first it means the underlying APIs have to know if you are logged in, not just the frontends (all public/private caching caveats apply).
This matches what we'd spoken about before, so communication between services will be done by a service on behalf of a user (rather than independently, as in eLife's current usage).
Think about what needs to be shared between frontend services, it should be just knowing who is logged in. Anything else needs to go through the regular channels (APIs or in-browser events).
Individual services will still have their own session data (eg flash message after filling out a form).
There's definitely detail to flesh out, but good to close?
Yes, the individual services session can be left to their own implementation for example.