The current session system relies on dedicated sessions for every user, regardless of their login state. This means that every guest gets assigned an own session which comes with two distinct cookies, the session cookie and the XSRF token. Most of the time guests are simply browsing the site without performing any actions that trigger a state change or any other requirement for a persistent session.
The Problems with the Existing Implementation
This comes with three distinct problems in every day use:
The session table is a common hot spot in the database due to the high frequency of writes to it. The use of a non numeric primary key adds further load by requiring frequent tree rebalances.
It is virtually impossible to cache the output of a page using simple tools like caching proxies or other sort of stateless caching systems.
Two cookies need to be set for every guest and while they fall into a class of cookies that do not require consent, it still creates some level of confusion.
There are some cases where state is explicitly required, such as for the login or registration form, but this is a problem that should be solvable. There is also a class of components that rely on state by design, for example, keeping track of items in the cart of a shop system.
Possible Solution
Ideally the session will be lazily initialized the first time some data is being written to it or when the session id is being requested (?). At this point it is unclear how the XSRF token should be handled because a form must indicate that this is required now.
Possibly this can be handled on a per request basis where the controller (or something else on the page) reports that particular endpoint to be stateful.
Is There a Need for State?
Initializing the session system is still an expensive operation and most of the time we don’t even need stateful requests. Making things worse, once a session has been requested, everything becomes stateful even though for guests a lot of pages are still just fine being stateless.
The localStorage might solve a lot of these issues, for example, the shopping cart could be stored in the local storage and signed using HMAC. This would allow the client to render a dynamic shopping cart on a page for guests without requiring the response itself to be stateful. Guests can continue to be served cached pages with the relevant pieces being dynamically inserted which is possible without causing CLS if done right.
The current session system relies on dedicated sessions for every user, regardless of their login state. This means that every guest gets assigned an own session which comes with two distinct cookies, the session cookie and the XSRF token. Most of the time guests are simply browsing the site without performing any actions that trigger a state change or any other requirement for a persistent session.
The Problems with the Existing Implementation
This comes with three distinct problems in every day use:
There are some cases where state is explicitly required, such as for the login or registration form, but this is a problem that should be solvable. There is also a class of components that rely on state by design, for example, keeping track of items in the cart of a shop system.
Possible Solution
Ideally the session will be lazily initialized the first time some data is being written to it or when the session id is being requested (?). At this point it is unclear how the XSRF token should be handled because a form must indicate that this is required now.
Possibly this can be handled on a per request basis where the controller (or something else on the page) reports that particular endpoint to be stateful.
Is There a Need for State?
Initializing the session system is still an expensive operation and most of the time we don’t even need stateful requests. Making things worse, once a session has been requested, everything becomes stateful even though for guests a lot of pages are still just fine being stateless.
The
localStoragemight solve a lot of these issues, for example, the shopping cart could be stored in the local storage and signed using HMAC. This would allow the client to render a dynamic shopping cart on a page for guests without requiring the response itself to be stateful. Guests can continue to be served cached pages with the relevant pieces being dynamically inserted which is possible without causing CLS if done right.