116

This may be a convoluted question, but I'm trying to get a better understanding of statelessness.

Based on what I've read, web applications should be stateless, meaning each request is treated as an independent transaction. As a result, Session and Cookies should be avoided (as both of them are stateful). A better approach is to use Tokens, which are stateless because nothing is stored on the server.

So I'm trying to understand, how can web applications be stateless when there is data that is being kept for my session (such as items in a shopping cart)? Are these actually being stored in a database somewhere and then periodically being purged? How does this work when you are using a token instead of cookies?

And then as a related question, are the major websites (Amazon, Google, Facebook, Twitter, etc.) actually stateless? Do they use tokens or cookies (or both)?

  • 40
    I've seen and talked to developers lately who are obsessed with statelessness to the point of distraction. Its nice to have statelessness for re-usability but its not realistic to pursue that goal in every situation over every other goal unless you have a ton of resources to do that for some reason, like scaling. – Mark Rogers Apr 10 '17 at 02:49
  • 5
    @MarkRogers Why? Statelessness has nothing to do with reusablility. And being stateless doesn't leads to an higher effort. – Paul Wasilewski Apr 10 '17 at 10:40
  • 3
    @PaulWasilewski: *And being stateless doesn't leads to an higher effort.* => it does, with a stateful application you keep everything in memory tied to the session. This does not scale well, though works with session pinning, but it's VERY simple. When servers need to start exchanging information between each others, troubles start. – Matthieu M. Apr 10 '17 at 13:46
  • 6
    Looking at amazon, you'll notice that your cart remains even if you change computer, so it is not stored in cookie, but rather in a database. – njzk2 Apr 10 '17 at 13:55
  • 20
    If you don't get around to reading my answer. Here's the short version: Web requests are *inherently* stateless. Web *applications* are not. (No matter what some "stateless web" dogmatists tells you!) – svidgen Apr 10 '17 at 14:54
  • 1
    @svidgen only if you consider database as part of the application. – njzk2 Apr 10 '17 at 14:56
  • @svidgen can't your application depend on other applications? – njzk2 Apr 10 '17 at 15:08
  • 3
    @svidgen so, in that case, for you, the only applications that are stateless are those that never really do anything. – njzk2 Apr 10 '17 at 15:13
  • 1
    @njzk2 Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/56869/discussion-between-svidgen-and-njzk2). (I've deleted some of my comments, since they're in chat now.) – svidgen Apr 10 '17 at 15:17
  • 1
    but aren't cookies some sort of "token" anyways? They're added to the headers of the request. That's the exact same thing you do with a token. Except you call it a token and not a cookie. – ILikeTacos Apr 10 '17 at 23:54
  • @ilikebeanstacos Web tokens in this sense have a signed payload, like an identity, possibly some authorizations, etc. – svidgen Apr 11 '17 at 05:01
  • For me, real stateless application is `/bin/ls`. On the other hand, Midnight Commander, Finder, Explorer are stateful applications. – el.pescado - нет войне Apr 11 '17 at 11:07
  • 1
    Possible duplicate of [Understanding the stateless internet](http://softwareengineering.stackexchange.com/questions/37836/understanding-the-stateless-internet) –  Apr 11 '17 at 15:24
  • 1
    As several people point out (and I think @sideshowbarker does it best), it is not a goal for web *applications* to be stateless, but it is a goal for the application *protocol* to be a stateless as possible. The same request should have the same meaning and the same result as much as possible, and their meaning should rely on past history as little as possible. This makes applications much easier to test. – reinierpost Apr 11 '17 at 19:56
  • @Snowman Not sure how this can be a "duplicate" of a question that was closed years ago. If this is a duplicate then the old question, with its 12 answers, needs to be reopened. –  Apr 12 '17 at 15:32
  • @nocomprende since when is that a requirement of being a duplicate? –  Apr 13 '17 at 01:15
  • 2
    @Snowman maybe the rules don't make sense to me, but it seems that if a question keeps arising, there needs to be one official answer, not just keep trying to squash it. Referring to a closed question is like pointing someone to a locked door. –  Apr 13 '17 at 11:01
  • 1
    @nocomprende a closed question with plenty of answers. It is not locked, either: the only restriction is new answers cannot be added. The fact that a question keeps arising is an indication that people do not search first before asking: that is why the site gives us the duplicate close reason in the first place. –  Apr 13 '17 at 19:57
  • @njzk2 seems to be saying layers can be stateless, which is true, but for some reason they insist on calling their layers applications. – user253751 Apr 26 '17 at 03:45
  • Interestingly, Amazon do have a whitepaper that answer this question in detail, see page 12 of this whitepaper: https://d1.awsstatic.com/whitepapers/AWS_Cloud_Best_Practices.pdf. Their view basically echos other answer below. – Ng Sek Long Mar 22 '20 at 13:45
  • This article is interesting in the sens where it shows the general way we should think about it. Software engineering is an organic matter : https://skiplist.com/insights/blog-software-principle-10-keep-state-at-the-edges – StackHola Oct 11 '22 at 10:55

8 Answers8

104

"web applications should be stateless" should be understood as "web applications should be stateless unless there is a very good reason to have state". A "shopping cart" is a stateful feature by design, and denying that is quite counter-productive. The whole point of the shopping cart pattern is to preserve the state of the application between requests.

An alternative which I could imagine as a stateless website which implements a shopping cart would be a single-page-application which keeps the shopping cart completely client-sided, retrieves product information with AJAX calls and then sends it to the server all at once when the user does a checkout. But I doubt I have ever seen someone actually do that, because it doesn't allow the user to use multiple browser tabs and doesn't preserve state when they accidentally close the tab. Sure, there are workarounds like using localstorage, but then you do have state again, just on the client instead of on the server.

Whenever you have a web application which requires to persist data between pageviews, you usually do that by introducing sessions. The session a request belongs to can be identified by either a cookie or by a URL parameter you add to every link. Cookies should be preferred because they keep your URLs more handy and prevent your user from accidentally sharing an URL with their session-id in it. But having URL tokens as a fallback is also vital for users which deactivate cookies. Most web development frameworks have a session handling system which can do this out-of-the-box.

On the server-side, session information is usually stored in a database. Server-side in-memory caching is optional. It can greatly improve response time, but won't allow you to transfer sessions between different servers. So you will need a persistent database as a fallback.

are the major websites (Amazon, Google, Facebook, Twitter, etc.) actually stateless? Do they use tokens or cookies (or both)?

Do they allow you to log in? When you then close the tab and revisit the site, are you still logged in? If you are, then they are using cookies to preserve your identity between sessions.

Philipp
  • 23,166
  • 6
  • 61
  • 67
  • 50
    I think one of the confusions here is the distinction between a "web application" in the broad sense of the user's perspective, and "web application" in the narrow sense of "the code running on the web server". It's the latter that is often argued to be stateless not the former. As you say, it makes no sense for the former to be stateless in general as state is usually part of the business logic. For the latter to be stateless simply means that state needs to be stored on the client or the database server or both and not on the web server. – Derek Elkins left SE Apr 10 '17 at 01:19
  • 16
    "[...] but then you do have state again, just on the client instead of on the server." It's about having no state on server side, to achieve better scalability and availability. If a state is stored on client side doesn't matter. – Paul Wasilewski Apr 10 '17 at 09:59
  • *But I doubt I have ever seen someone actually do that, because it doesn't allow the user to use multiple browser tabs and doesn't preserve state when they accidentally close the tab.* => There is this shiny new thing called [*local storage*](https://en.wikipedia.org/wiki/Web_storage#localStorage) which is tied to the domain. – Matthieu M. Apr 10 '17 at 13:45
  • 2
    saying that a shopping cart is stateful is like saying that a user's name is stateful. – njzk2 Apr 10 '17 at 13:56
  • 5
    @njzk2 can you elaborate so that this doesn't sound absurd? Users don't go to Amazon to buy more names. And, after they make their purchase, *something* disappears which only existed while they were shopping. If that something is not "the state of the application", then what is it? If applications do not have state, what do they have? –  Apr 10 '17 at 14:00
  • 3
    @nocomprende: I think njzk2's general gist is that the contents of your cart, like your full name, is data that a webapp persists on the server side. When people say, "webapps should be stateless", they usually mean something different from "webapps should not access a database containing your full name associated with your username". Precisely what they *do* mean by "stateless" perhaps is not trivially defined, since once you have that database there's all kinds of nonsense that you could persist in there, to support overly-complex app state, but shouldn't ;-) – Steve Jessop Apr 10 '17 at 14:12
  • @SteveJessop so, the web*app* does the persisting, it is in charge of the state. What it does with it is academic, it could store it in a reverb unit for all we care. An *app* that is stateless must either not do very much, or be a contradiction in terms, no matter what hardware it runs on. The OP was not spitting such hares, he was asking about the application. –  Apr 10 '17 at 14:17
  • 1
    @nocomprende: no, the people who make the statement "webapps should be stateless" are the ones who need to split hairs, since they need to define what they mean. – Steve Jessop Apr 10 '17 at 14:18
  • 2
    @SteveJessop So the questioner is confused because someone who should know better has used words poorly. How do we unscramble the egg now? –  Apr 10 '17 at 14:19
  • 4
    @nocomprende: unscramble an egg by rolling back the database: since our webapp is stateless it can resume as before ;-) – Steve Jessop Apr 10 '17 at 14:20
  • @SteveJessop Ahh, the good old days, nanoseconds after the Big Bang, before everything got so complicated :) –  Apr 10 '17 at 14:21
  • 2
    @nocomprende in most cases that I can think of, stateless does not include much in terms of database. Simply put, you can consider your database outside of the application, and voila. (But then people will put complex state in database, so...). If you consider database as state, then the only stateless application is basically immutable. – njzk2 Apr 10 '17 at 14:58
  • @njzk2 what's wrong with saying your backend/frontend **component** or **layer** is stateless instead of a backend/frontend "application"? – user253751 Apr 26 '17 at 04:23
  • @DerekElkins Unless I got mixed up in all the latter/former phrasing you are using, I would argue that business logic should be implemented server side not client side, and that the client side should be as stateless as possible. Your business logic (that should be server side) could be statefull if need be. You should be able to "plug" your backend to another frontend and your business logic stays untouched. – Sebastien Nov 28 '18 at 14:49
67

It's true that web applications should be stateless. However, session variables, cookies, and tokens don't violate this when they are all stored on the client (web browser). They can be parameters in the request.

Here's a simplified model:

Web Browser (has state) <-> Web Server (stateless) <-> Database (has state)

This could work for Software Engineering Stack Exchange. This answer I'm typing is part of my web browser's state. So long as that's the only place where it is, it's not accessible to anyone but me. But as soon as I hit Post your Answer my browser sends it to the web server. The web server processes the post using no state of its own. It learns who I am from my browser and from the database. Once it's done checking my post, and adding it to the database, the web server promptly forgets about me.

That's what stateless means. The server is not responsible for remembering any of this. That's not its job.

Doing this has many advantages. If the web server has a memory leak it's detectable since its memory footprint shouldn't be growing. If the web server crashes, my identity doesn't go with it. If someone tries to do a denial of service attack, they can't use web server state resources to do it, because the web server doesn't allocate any state for them between sessions. This is all aimed at making the web server stable. That way, when it starts running, it stays running.

Now sure, I'm consuming resources in the database, but those resources have first been checked against my allowance by something stable that we can count on to protect the database from the wild and woolly web: the stateless, business rule enforcing web server.

candied_orange
  • 102,279
  • 24
  • 197
  • 315
  • Thanks for the explanation, but are Session Variables really stored on the Client Side? I thought most mechanisms (such as asp.net) store it Server Side. –  Apr 10 '17 at 04:08
  • 1
    @Awake Well, that just depends on how you build your web server and code/framework that runs on top of it, right? The web server itself could store it in its own memory, or it could just ask the database backend (which may or may not be on the same host/server) to create an entry, get back a unique ID from the backend, and send that ID back to the client, immediately forgetting about it until the client sends the next request with the same ID, at which point it could just look the ID back up in the database. I'm not very familiar with ASP.NET, but I imagine it has some way of doing this. – mtraceur Apr 10 '17 at 06:18
  • 10
    I don't know... This answer sounds a bit like saying: "*Excel* doesn't store your spreadsheet, the disk drive does!" Ha ha, isn't the database *part of* the web server, as far as most people are concerned? Obviously state is not stored in the CPU or code of the server, and keeping it all in memory is pretty silly. –  Apr 10 '17 at 12:17
  • 9
    @nocomprende No, the database is usually not part of your web server. Yes, storing state in a database quite possibly limits scalability of the overall application, but there are relatively few applications that can offload *all* of their state (or even all the "per user" state) onto the client. Database servers are specifically designed to scalably handle state and, as CandiedOrange mentions, they're usually better protected, provisioned, and vetted than web servers. There are benefits to being easily able to scale web servers even though that doesn't solve all scalability problems. – Derek Elkins left SE Apr 10 '17 at 12:32
  • For my purposes, "part of" means that it cannot do something useful by itself. A transmission is not *part of* an engine, but neither one can do anything by themselves so it is more useful to talk about the *car* instead. A giant database server cannot do anything on its own, and a web server (using your definition) can't do anything useful without storage, so it is better to use the term "web server" to mean the combination, regardless of what academic distinctions can be made. If you are unwilling to see your term used this way, please tell me what to call "it" (thing that handles requests). –  Apr 10 '17 at 12:52
  • 3
    @nocomprende well your right. But when people talk about the servers need to be stateless this is where it comes from. You can solve this problem many different ways. But the traditional solution is to make state something else's problem. – candied_orange Apr 10 '17 at 12:57
  • The world would be a better place if computers never stored any information. –  Apr 10 '17 at 12:58
  • Heh, well you'd get perfect security and no bugs. Just wouldn't have many features :) – candied_orange Apr 10 '17 at 13:01
  • 13
    @nocomprende: The point of saying that the database is not part of the webserver is that you can have a single database (or database cluster) for 1, 2, 3, .... webservers. This is how being stateless is meant to increase scalability: you can scale the database cluster and the number of webservers independently. – Matthieu M. Apr 10 '17 at 13:50
  • 2
    @MatthieuM. It is interesting that the question asked about a stateless *application* and we are talking about hardware. It think this is a digression. The questioner wanted to learn about tokens, cookies and so on, and we are dividing up the racks of machinery. Something has gone off track. –  Apr 10 '17 at 13:55
  • 2
    @nocomprende: It may be because the OP operates on a false premise. It's not web applications that should be stateless, it's the webservers tier. I think this is where their confusion stems from, and thus why this answer is good in that it explains the different actors at work. – Matthieu M. Apr 10 '17 at 14:00
  • @MatthieuM. So is it not possible to just talk about applications? Servers have to come in to it? This is like in "Zen and the Art of Motorcycle Maintenance" where the question about the light bulb and the switch was not able to be answered: you have to know that the speed of electric conduction is effectively infinite. This is why I quit Philosophy: it answers questions only understandable to Philosophers. –  Apr 10 '17 at 14:08
  • 6
    "It's true that web applications should be stateless." No. This is complete nonsense. – svidgen Apr 10 '17 at 14:47
  • 1
    @nocomprende: It's certainly possible to talk about applications (and software components), but the application resides in a physical universe, and various aspects of that physical universe are relevant to various aspects of the application's design. – ruakh Apr 10 '17 at 18:59
  • 1
    @nocomprende if it helps, talk about _instances_ of the web application rather than web servers. If you have 10 instances of a stateless web application properly load balanced, any one of them can handle any request from any client. All the information needed to process the request comes in the request (even if a db lookup is needed, what to lookup is part of the request.) When the request is processed all the results request are pushed off (back to the client and or db), and the instance releases any local resources it used to process the next request. – Mr.Mindor Apr 10 '17 at 19:30
  • 1
    @nocomprende The whole argument of web apps being stateless *is* a hardware concern; the need to horizontally scale only arises because of hardware limitations. On infinitely powerful and perfectly reliable web servers, there would be no need for web apps to be stateless, since we would never need to horizontally scale anything. – wavemode Apr 11 '17 at 08:48
  • @wavemode Well, the hardware seems to be improving very much faster than our brains and understanding does. So eventually we can forget the whole issue and just go back to writing applications. To me, the hardware aspect is an unimportant concern. Storing data is important. –  Apr 11 '17 at 11:55
  • 5
    This answer is the one I like the best because it best illustrates the usage of "stateless" in web dev. The server isn't maintaining state between requests. All state must come from the client (ie, part of the request) or from the database (likely based on the request). As an aside, there totally often is *some* state in the web application (eg, static instances of stuff), but in general, you'd want to design things to be stateless. This answer seems better than the accepted one for actually explaining the idea of statelessness best. – Kat Apr 11 '17 at 22:01
  • But, of course, one has to be careful about what they keep on the client because this is inherently [less secure](https://www.owasp.org/index.php/Session_hijacking_attack). – Akshat Mahajan Apr 12 '17 at 01:49
  • @nocomprende I don't really understand what you're driving at here - the motivation behind a stateless application is that you can cluster it and scale it dynamically by spinning up new instances without worrying about data consistency between those instances (because the state of the *system* is externalised from the physical *application*). If you're not interested in talking about physical architecture then entering a discussion about whether or why web applications should be stateless is a bit counterproductive. – Ant P Apr 12 '17 at 07:12
  • @AntP no, I am simply drawing a meaningful line between 'application' and 'physical architecture' because the question asked about applications. The discussion has actually focussed on the layer between those two. I know, because I built a successful multithreaded, multiprocess database transaction server shell. The *application* was something else entirely, and could have run against a completely different server design. You can't talk meaningfully if levels are all thrown together. As someone else said, a stateless application is a contradiction. –  Apr 12 '17 at 11:57
  • Silly explanation: for the server I built, there were two clients - a browser-based one, and a PC distributed database one, which also stored images associated with the data entities. *Was "the application" stateless?* My server did not care. The thread code I wrote to handle requests would have worked for one thread (like the Apache server at that time - 2001), or 100, and the server process could fork off child server processes which each had a pool of available thread slots. No application was in sight there. –  Apr 12 '17 at 14:37
  • @nocomprende still not sure what your point is - if you want to run multiple instances of a web application behind a load balancer, for example, you need to concern yourself that the state they manage is externalised from individual instances and shared. That is what is commonly referred to as making the web application stateless. You seem to be more concerned with the semantics of what constitutes an application than actually discussing anything of practical relevance to the question. – Ant P Apr 14 '17 at 07:27
32

web applications should be stateless

Nonsense. Web requests should be stateless. Or more accurately, web requests are stateless.

But, saying that a whole application should be stateless is complete nonsense.

each request is treated as an independent transaction.

Yes, exactly. Or more accurately, yes, necessarily. Over HTTP, each request is inherently independent of all other requests. Adding "statefulness" to HTTP requires that you explicitly identify, store, and retrieve "state" for each "stateful" request. And that takes effort, decreases performance, and adds complexity.

And, for those reasons, each request that can be stateless "should" be stateless.

As a result, Session and Cookies should be avoided (as both of them are stateful). A better approach is to use Tokens

A few things: Tokens can be tied to session storage too. Cookies don't need to be tied to session storage. Tokens are often stored in cookies. And, sometimes a session is simply the right tool for the job.

That means that at least sometimes, sessions and cookies are just as "better" as tokens!

[Tokens] are stateless because nothing is stored on the server.

Well, that's it. That's what the "statelessness" dogma is really about. Though, to be clear, it's not about storing "nothing" on the server, it's about not storing session state on the server.

My Gmail inbox is in a state, for example. And it damn well better be stored on the server! But, it's not session state.

So, instead of having a servers that can take a small identifier and figure out who you are and so forth, stateless applications want to be reminded who you are and what you're doing with every bloody request. The application state still exists, the client is just responsible for holding onto it.

Now, if that state is small, that's probably OK. In some cases it's very good.

And then, of course, there are things we simply expect to be stateful ...

how can web applications be stateless when there is data that is being kept for my session (such as items in a shopping cart)? Are these actually being stored in a database somewhere and then periodically being purged?

Two options. Either you have a session, or you're in denial!

... But seriously. You wouldn't normally store a cart in a cookie. Something like a shopping cart will either be stored in a "traditional" session, or it'll be stored as a Cart object, with some kind of ID that the server uses to pull it into subsequent requests. Kind of like a .. uhh ... ... err ... session.

For real seriously: There's a large degree to which "statefulness" is just what we call it when two communicating agents can contextualize messages in a conversation. And a session, traditionally understood, is just what we typically call the mechanism by which this occurs.

I'd argue that, regardless of whether you use tokens or "sessions," for each request your server handles, you either need to contextualize that request to fulfill it, or you don't. If the context isn't necessary, don't fetch it. If the context is necessary, you better have it nearby!

And then as a related question, are the major websites (Amazon, Google, Facebook, Twitter, etc.) actually stateless? Do they use tokens or cookies (or both)?

Probably both. But, generally speaking, they do exactly what you do: They set cookies to identify "state" records in massive "session" databases.

When possible, I suspect they shove basic identity claims into short-lived "tokens" to avoid unnecessary contention on centralized storage. But, the fact that many of these services permit me to "log out of all other locations" is a good indicator that, if they're using tokens at all, they're at least "supported" by a semi-traditional session model.

svidgen
  • 13,414
  • 2
  • 34
  • 60
  • 3
    Agree. It reminds me of the "immutable data" idea. If it is immutable, carve it in a rock, don't waste a computer to do that. Let computers do stuff with data! That is why we built them! Applications work with data. Data that is constant is useless. –  Apr 10 '17 at 19:47
  • @nocomprende FYI, I will be making an addendum to this later. I feel like my answer's missing part of the OP's underlying question. Because, there *is* a legit concern floating behind the "stateless application" idea. But, the answer is along the lines of, *when people say 'stateless', what they **mean** to say is 'relies minimally on server-side sessions.'* – svidgen Apr 10 '17 at 19:53
  • 4
    @nocomprende: immutable data structures is something different, and is a tool used to manage lifecycles of memory objects. – whatsisname Apr 11 '17 at 02:07
  • 1
    Love your first line of explanation. When we discuss something, each verbal statement we make instantly dies away into oblivion. But somehow, we are still able to carry on a conversation, eh? It's *Magic!* –  Apr 12 '17 at 14:48
  • @nocomprende Statements don't die away into oblivion - we're keeping the state and history of the conversation in our own memories, albeit imperfectly. – pabrams Feb 22 '18 at 17:21
  • @pabrams well it is a darn good thing that people do not function like web servers! –  Feb 22 '18 at 17:34
  • @nocomprende Well, maybe parts of our brains do function like web servers, but make calls to other parts of our brain that function like databases... – pabrams Feb 22 '18 at 18:02
  • @pabrams What I meant was that another 'me' can't just walk up and take over for... me. Or *you*, for that matter. The only unsolved problem in computer use these days is how to identify a person. If we could solve that, there would be no identity theft, no fraud, no criminality of any kind that depended on computers. *sigh* –  Feb 23 '18 at 14:19
  • 1
    @nocomprende This is an interesting discussion, but I guess we shouldn't continue it here. – pabrams Feb 23 '18 at 16:14
16

Statefulness is not necessarily a bad thing, but you need to understand the difference between stateful and stateless apps. In short, stateful apps maintain information about the current session, and stateless apps do not. Information stored permanently as part of a user account may or may not be stored in a session, but storing information related to a user account does not by itself make the application stateful. Statefulness requires that the server maintain information about the current user's session beyond what the client browser is maintaining. For instance, a client could authenticate and be given a JSESSIONID cookie, which it then sends to the server with each request. If the server starts storing stuff in the application's session scope based on this JSESSIONID, it becomes stateful.

Statelessness

By stateless, we mean that the server and client are not maintaining current information about the user session. The client and server may use some form of token to provide for authentication between requests, but no other current information is stored. A typical use case for such a solution might be a news site where most users (new consumers) consume information but do not produce information that goes back to the site. In such cases, the site doesn't need to maintain any information about the current user session. Note that the site may still use cookies to identify the user and store information about that user's use of the site, but that may still be regarded as stateless since everything recorded could be transactional, e.g. what link the user clicked, which might be recorded by the server, but not maintained in a user session.

Statefulness on the server

On the server, a stateful app saves state information about current users. This approach generally involves using cookies to identify the user's system so that state can be maintained on the server between requests. Sessions may or may not be authenticated, depending on the context of the application. Stateful server apps offer the advantage of caching user state information on the server, speeding up lookups and page response time. On the down side, storing information in session scope is expensive, and at scale it becomes very resource intensive. It also creates a potential attack vector for hackers to try and hijack session identifiers and steal user sessions. Stateful server apps also have the challenge of protecting user sessions against unexpected service interruptions, e.g. a server failure. A common solution to this problem is to cluster sessions across a cluster of server machines, but again, at scale it quickly becomes impractical to cluster all sessions across all machines.

Statefulness on the client

Using JavaScript and modern browser technologies like sessionStorage, application can now easily store state information about a user session on that user's device. Overall, the application may still be considered stateful, but the job of maintaining state has been moved to the client. This approach has a big advantage (for the maintainer of the Web app) over maintaining state on the server in that each user is, in effect, maintaining their own state, and there is no burden on the server infrastructure. At web scale, that kind of architectural choice has huge repercussions for hardware and electricity costs. It could literally cost millions of dollars a year to maintain state on the server. Moving to a system maintaining state on the client could then save millions of dollars a year.

Tokens v. cookies

Cookies act as identifiers for client devices/browsers. They can be used to store all manner of things, but generally they store some form of identifier, like CFID/CFTOKEN in CFML apps. Cookies can be set to live in the user's browser for a long time, making it possible to do things like maintain authentication on an app between browser sessions. Cookies can also be set to memory-only so they expire when a user closes the browser.

Tokens are generally some kind of identifying information about the user that are generated on the server ( using encryption to scramble the information ), passed to the client, and returned to the server with the subsequent request. They may be passed in the header of the request and response, which is a common pattern in single page applications. Ideally, each request/response results in the generation of a new token, so tokens can't be intercepted and used later by an attacker.

Single Page Apps and client state

With SPAs, state information is loaded into the client browser and maintained there. When the state changes, e.g. you post an update to your social media account, the client relays that new transaction to the server. In this case, the server saves that update to a persistent data store like a database, and relays whatever information back to the client that it needs to synchronize with the server based on the update (e.g. an ID for the update ).

Note that this pattern of storing state on the client offers advantages for online/offline experiences in that you can be disconnected from the server while still having a somewhat usable application. Twitter is a good example of this case, where you can review anything loaded client side in your Twitter feed even if you are disconnected from the Twitter server app. This pattern also creates complexity in synchronization between server and client, which is a whole subject of its own. The complexities of the solution are a tradeoff for being able to maintain state on the client.

Statefulness on the client makes web apps feel and behave more like traditional desktop apps. Unlike desktop apps, you will typically not have all of your account information loaded into your client session in a browser. Doing so would in many cases be impractical and produce bad experiences. Can you imagine trying to load an entire Gmail box into the browser? Instead, the client maintains information like what label/folder you are looking at and where in the list of emails in that folder you are looking. Balancing what state information to maintain and what to request as needed is another engineering challenge of this pattern, and again, it represents a tradeoff between practicality and providing good user experiences.

Shopping carts and the like

As for specifics like shopping carts, it really depends on the solution. A shopping cart may be stored in a database on the server, it may be stored only in session scope on the server, or it may even be stored in the client. Amazon has persistent shopping carts for logged in users, and "temporary" carts for anonymous users, though these carts are persistent to some extent.

When you talk about something like Google, which is really a bunch of different applications living under the same brand, they probably do not share a common architecture, and each is built in the way that best meets the needs of its users. If you want to learn how a site is built, open the developer tools in your browser and look at it. Check for cookies, watch network traffic, and see how it runs.

Sorry if this answer rambles a bit, but statefulness is a complex subject.

Robert Munn
  • 1,221
  • 8
  • 6
6

Sessions and cookies don't have to be avoided. You can still have them with stateless web applications.

There is a big difference between Java and Ruby on Rails. Java apps will store the session in memory using a session key stored in a cookie. This is fast to retrieve the user state and shopping cart. However, you have to always hit the same server with your session.

Rails apps store the user id in a signed, encrypted cookie. It can't be tampered with. When you load a page, the web app fetches your state, user, and shopping cart from a database. This is slower, but the key is, you can hit any instance! This allows you to restart, scale, shutdown instances at will. Very convenient. It can also be made faster with a shared, in-memory, cache database like Redis. Or you can store the shopping cart in the cookie, provided it's small enough.

So you can achieve statelessness, through clever techniques, and add the ability to scale at will.

Chloe
  • 438
  • 1
  • 3
  • 10
5

The protocol is stateless.

But from that it doesn’t necessarily follow that applications using the protocol should be stateless.

Here are a couple of related StackOverflow answers that explain the difference well:

sideshowbarker
  • 397
  • 1
  • 6
5

When referring to stateless - e.g. in a RESTful HTTP Service - it's about to avoid storing state on the server side. At best, that includes also avoid storing any state in a database or other persistent storages on the backend. To make it clear I am talking about a state not data in general. It seems that some guys are mixing things up.

A stateless communication has several benefits especially regarding scalability and availability.

A better approach is to use Tokens, which are stateless because nothing is stored on the server.

That's true (for certain authentication and authorization protocols). Tokens can (but not per se) provide all information within the request which is needed to authenticate an user or authorize an action. For an example take a look at JWT.

So I'm trying to understand, how can web applications be stateless when there is data that is being kept for my session (such as items in a shopping cart)? Are these actually being stored in a database somewhere and then periodically being purged? How does this work when you are using a token instead of cookies?

Regarding the shopping cart example. It's no problem to store all the cart items on client side without using a session or cookies. You can find an example on smashingmagazine.com. But it's also possible to realize a stateless shopping cart with cookies (at least if your assortment is not so big and 4kb storage is enough for you).

Don't get me wrong, that doesn't mean you should implement a shopping cart stateless to any price. Amazon or other big online shopping platforms are using stateful shopping cart implementations because user experience and usability is more important for them than fitting technical non-functional requirements like scalability.

Generally, tokens are not used to store information like cart items. They are used for a stateless authentication and authorization.

And then as a related question, are the major websites (Amazon, Google, Facebook, Twitter, etc.) actually stateless? Do they use tokens or cookies (or both)?

If you are asking if they are using cookies or tokens for authentication, the the answer is they use both. For users mostly cookies for technical clients mostly tokens are used.

Paul Wasilewski
  • 296
  • 1
  • 5
-2

OK, the rule you quote is technically incorrect. All the layers of a web application have state.

The intent of the rule is "don't hold per-session state server side".

I.e., session variables in ASP, which were commonly used to do things like items in basket/user name, etc.

The reason is that you will run out of memory on the server as your application gains more users. Moving the storage to a database or shared cache doesn't solve the problem as you still have a bottleneck.

To maintain per-user application state without hitting this problem, move the state to the client side. For example, put the basket items in a cookie or more advanced client-side storage.

Because the number of clients scales with the number of users, your application as a whole won't have a bottleneck and will scale well.

Peter Mortensen
  • 1,050
  • 2
  • 12
  • 14
Ewan
  • 70,664
  • 5
  • 76
  • 161
  • 2
    While memory leaks and denial of service issues were a factor, I think a more significant driver nowadays is elasticity and robustness to failure of a web server which is, of course, also related to scalability. The idea is if a server gets overloaded or even crashes, I can just reroute future requests (and with a bit more care even replay failed requests) to new web servers without coordination or losing state (as the user sees it). – Derek Elkins left SE Apr 10 '17 at 07:46
  • hmm kind of. If you have per user info on the server, even if its distributed you still have a scalability problem. – Ewan Apr 10 '17 at 08:38
  • There's plenty you can do if pulling data from the disk is the bottleneck such as caching. – JeffO Apr 10 '17 at 21:07
  • no, there is an inherent problem if you hold that per session data. either you move it off the webserver to its own high availablity system or get rid of it all together by moving it to the client – Ewan Apr 11 '17 at 10:24
  • 1
    All this discussion about trying to avoid the hot potato really mystifies me. Whatever happened to the old saying, "The buck stops here"? *Something* has to manage the data, my bank would not like me keeping all of my financial transaction info only on my laptop. Why is everyone running away screaming from data? It is why we have computers! Crazy. –  Apr 12 '17 at 14:53