Comments on: Stateless Applications are an Illusion

By: Stateful or Stateless? « IT Primer

Stateful or Stateless? « IT Primer — Thu, 08 Dec 2011 03:21:42 +0000

[...] stateless applications are an illusion. A comment to that post nails it: “stateless applications are no applications, they are … ummm [...]

By: PaaS, much ado about network services « Rob Hirschfeld's Blog

PaaS, much ado about network services « Rob Hirschfeld's Blog — Wed, 22 Sep 2010 15:35:07 +0000

[...] an application can be written as stateless code (really “externalized state” is more a accurate description) that relies on these services for [...]

By: AJ

AJ — Wed, 07 Apr 2010 19:42:32 +0000

I think that Wicket is a perfect framework for holding state in the web tier. It is also possible in Wicket to make your own page store (thing that keeps state) and possible to make a Redis implementation (isn’t that already available).

By: stephan

stephan — Sat, 03 Apr 2010 05:29:48 +0000

@Vic:

You: “Stephan, Why do not save session state on client side if you [...]”

To quote the article: “1. Best state store: Client (window.name hack, Javascript variables for AJAX applications Cookies)

Cheers
Stephan

By: stephan

stephan — Sat, 03 Apr 2010 05:29:05 +0000

@Subbu: They run all without holding any state? How is that? (which fields should be sorted, auto safe, …)

Gmail has extensive state, I guess holding it in JS variables as mentioned in the post. I don’t use other web email apps, perhaps you could point me to one without any state holding?

By: Subbu Allamaraju

Subbu Allamaraju — Sat, 03 Apr 2010 05:18:25 +0000

+1 to Stefan Tilkov’s comment. There are a lot of really large-scale apps (emails, shopping carts) are running fine without doing any of the hacks you mention. Sessions do not scale. The tradeoffs shouldn’t be taken lightly.

By: Vic

Vic — Fri, 02 Apr 2010 14:01:53 +0000

Stephan, Why do not save session state on client side if you need cheap solution for scalability. If state is on client side you can redirect client from one node to another easily and without any consequences.

By: stephan

stephan — Fri, 02 Apr 2010 12:15:17 +0000

@Tim: Depends what you want. If you want the person to have two browser see each other, key the data the user, not the session ID. If you don’t, then have seperate sessions. What the product managers wants, two conversations or one conversation in two browser windows. But going with a seperate session store (like memcache) doesn’t solve your problems magically, you still need to think what you want.

As I’ve said, keeping state as close as possible to the client is best, so a cookie or the page works fine, the page is often hard though, and often leads to ugly URLs (most people do not want that) or to a lot of POST requests (which break the back button).

By: Tim Jansen

Tim Jansen — Fri, 02 Apr 2010 09:53:44 +0000

I don’t think that losing the state in the server is the main problem, but rather implementing it correctly. Back buttons, reloads, double clicks on links/buttons and sometimes even new tabs are all working fine in multi-page forms as long as you keep all conversational state in the form as hidden fields. But when you store things on the server, you need to deal with them (undo parts of the conversation, or even duplicate the conversational state and open a second conversation).
Are there any frameworks that handle this correctly?

By: stephan

stephan — Fri, 02 Apr 2010 05:52:25 +0000

@Vic: Contrary, if you want to scale cheap, you need to use web-tier state, scaling with the “rails-memcache-state-model” will cost you dearly in servers.

By: Vic

Vic — Fri, 02 Apr 2010 05:42:11 +0000

Look at “Fallacies of Distributed Computing” http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing. If you do not want to have headache, try to avoid session state on server side if you have to support scalability.

By: stephan

stephan — Fri, 02 Apr 2010 05:35:26 +0000

@Itay: Yes (1) does not scale – neither for users, nor for the complexity of the code in multi-page applications

By: Itay Maman

Itay Maman — Fri, 02 Apr 2010 05:16:46 +0000

I think that in general case, statlessness (as advocated by functional programming) is an illusion. When you’re absolutely stateless every cycle of interaction of the user with app (be it a web-app, a GUI app, whatever) requires:

(1) That the entire data relevant for the processing be specified as a parameter(s);

(2) That the entire output (incl. UI elements, DB records, whatever) will be returned as a result

I’m afraid that upholding these requirements is not feasible (and, alas, will not be feasible even if when our frameworks/languages evolve). You do not want to encode every tiny state of the UI as a parameter that is passed to the interaction. If encode the entire state of the app and return it as a result interaction of one user will not be seen by the next user.

By: stephan

stephan — Fri, 02 Apr 2010 04:51:12 +0000

@JeanHuguesRobert: Which means in a conversation state store on the server? The variables are just an abstraction for that (not that this is bad)

By: Daniel Alexiuc

Daniel Alexiuc — Fri, 02 Apr 2010 00:56:06 +0000

The server side Web tier *used* to be the ‘easiest’ place to store state, simply because there were many very popular web frameworks to enable this – written by people who really didn’t think hard enough about the problem.

It doesn’t change the fact though that it is the “worst” place to store web application state. Web application state belongs on the client, and thankfully there are now many client side frameworks that help with this.

By: JeanHuguesRobert

JeanHuguesRobert — Thu, 01 Apr 2010 22:10:08 +0000

It has always been strange to me that, because HTTP is not a connection oriented protocol, as a result applications should be stateless too.

It is like removing local variables from all computer languages, expecting developpers to build massive finite state machine, or, even more difficult, pushdown automaton.

Seaside put them back with the notion of modal http server. AFAIK the state is where it belongs, in the stack, in local variables.

By: stephan

stephan — Thu, 01 Apr 2010 21:18:27 +0000

@Stefan: As most often – you are right

@Stefan: I beg to differ, putting to a session scoped resource like a basket, stored in a database, is just that: tansient communication/conversation state, everything are just word games.

Cheers Stephan

By: Stefan Tilkov

Stefan Tilkov — Thu, 01 Apr 2010 20:22:44 +0000

IMO, in a Web app, each individual request should contain enough information to be processable independently of whether or not a previous request did or did not occur. Persistent server-side resource state is fine, client-side state is fine, transient communication (session) state isn’t because it’ll ruin scalability and bookmarkability, one way or the other.

By: Stefan Schubert

Stefan Schubert — Thu, 01 Apr 2010 19:14:20 +0000

If you define it that way as you do your headline should be “stateless applications are no applications, they are … ummm … static”

Cheers :-)
Stefan