Storing session state in browser's local storage

Question

Stack Exchange has some bits of what seems to be session state -- for example, whether you want to see 15, 30, or 50 questions per page when you view a list of questions.

You can click on the button at the bottom of the list to change the setting, that value is a URL query parameter, and thereafter the new setting is remembered (without being a query parameter):

• https://softwareengineering.stackexchange.com/questions?sort=active&pagesize=30

Another piece of state is which tab you prefer: "Active", "Newest", etc.

It's not something you explicitly set when you edit your user profile settings (perhaps because it's too small a detail to be worth configuring in that way).

Anyway, I wondered if that session state is stored on the client or on the server.

I looked in my browser's local storage for the site, and I find there a bit of state -- i.e. related to the selection of Winter Bash hats -- but not the state related to list length and sort order.

My question is:

• What's the difference between storing session state on the client versus the server?
• Why would SE decide to store this bit of state be stored on the server instead of the client?

---

Off the top of my head:

• Server-side state is good because it works consistently, independently of which browser and/or machine a user uses

• Server-side state is said to be bad because it's not RESTful, makes web farms difficult -- but apparently people don't worry about that, and just store the session state in the database (shared by all web servers) instead of within each web server:

  The session state can be transferred by the server to another service such as a database to maintain a persistent state for a period and allow authentication.

Is there more to it than that -- what else would you consider when deciding whether session state like this should be stored client-side (in local storage) or server-side (in database)?

It seems to me that either is adequate so it's hard to choose. Making the session state portable from one browser to another (by storing it on the server) is clever but maybe not important for such minor details (I understand why you'd store the User Profile Settings in the database). So on balance, maybe client-side is the neater choice -- but that's not what SE chose.

Do you happen to know the reason for SE's choice?

Answer 1

Almost everything is a balancing act between performance, usability, maintainability. That said...

• What's the difference between storing session state on the client versus the server?

Where the information is stored determines where it is accessible from. If you only store something client-side, the server obviously won't have any knowledge of it.

The term "session state" is more often used for more transient information than what is being discussed here, to do with the specifics of the user's session. It's short-lived, and so doesn't often justify living in the persisted database -- which is why people will often store it in-memory on the web server, and that's where the problems come in from having multiple web servers.

• Why would SE decide to store this bit of state be stored on the server instead of the client?

The list of questions on the page returned is something the server needs to provide. The number of questions the user wants, and how they are to be ordered, are important pieces of information for building up the response to your request when you go onto the Stack Overflow home page.

That the information isn't changed on the user profile page, doesn't mean that the data doesn't form part of the user profile -- just that it's edited elsewhere. You shouldn't take the editable fields of your profile as the extent on the data stored about you on the site; there's probably a lot of little pieces like this which are useful to track but would be overly detailed from the profile page point-of-view.