Timeline for How to keep applications stateless
Current License: CC BY-SA 3.0
18 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 28, 2018 at 14:49 | comment | added | Sebastien | @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. | |
| Apr 26, 2017 at 4:23 | comment | added | Stack Exchange Broke The Law | @njzk2 what's wrong with saying your backend/frontend component or layer is stateless instead of a backend/frontend "application"? | |
| Apr 11, 2017 at 21:45 | vote | accept | CommunityBot | ||
| Apr 10, 2017 at 14:58 | comment | added | njzk2 | @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. | |
| Apr 10, 2017 at 14:21 | comment | added | user251748 | @SteveJessop Ahh, the good old days, nanoseconds after the Big Bang, before everything got so complicated :) | |
| Apr 10, 2017 at 14:20 | comment | added | Steve Jessop | @nocomprende: unscramble an egg by rolling back the database: since our webapp is stateless it can resume as before ;-) | |
| Apr 10, 2017 at 14:19 | comment | added | user251748 | @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, 2017 at 14:18 | comment | added | Steve Jessop | @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. | |
| Apr 10, 2017 at 14:17 | comment | added | user251748 | @SteveJessop so, the webapp 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, 2017 at 14:12 | comment | added | Steve Jessop | @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 ;-) | |
| Apr 10, 2017 at 14:00 | comment | added | user251748 | @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, 2017 at 13:56 | comment | added | njzk2 | saying that a shopping cart is stateful is like saying that a user's name is stateful. | |
| Apr 10, 2017 at 13:45 | comment | added | Matthieu M. | 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 which is tied to the domain. | |
| Apr 10, 2017 at 9:59 | comment | added | Paul Wasilewski | "[...] 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. | |
| Apr 10, 2017 at 1:19 | comment | added | Derek Elkins left SE | 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. | |
| Apr 9, 2017 at 22:59 | history | edited | Philipp | CC BY-SA 3.0 | added 13 characters in body |
| Apr 9, 2017 at 22:52 | history | edited | Philipp | CC BY-SA 3.0 | added 428 characters in body |
| Apr 9, 2017 at 22:45 | history | answered | Philipp | CC BY-SA 3.0 |