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?

  • Note that there are a variety of client-side storage mechanisms. In additional to Local Storage, there is Indexed DB, and most importantly: Cookies. In this particular case, none of them seem to be used though.
    – amon
    Commented May 19, 2019 at 11:03

1 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.

  • Thanks, I hadn't even thought of that. I imagined that the client-side could include bits of session-state in the requests it sends to the server -- e.g. even if the browser "location" appears to be https://softwareengineering.stackexchange.com/questions the client-side script might actually send https://softwareengineering.stackexchange.com/questions?pagesize=30 if the page size were stored in local storage. Perhaps that's my assuming too much interference though, in the operation of the browser by the client-side script.
    – ChrisW
    Commented May 19, 2019 at 10:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.