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):
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?