More on stateless web apps

I thought I’d expand on my previous point. It’s a simple one, but they’re always the trickiest.

Web apps are by their nature stateless. Stateless applications are a pain in the butt to build, because they are extremely complex (not just complicated). By stateless, what I really mean is that the client state and the server states are disconnected. This is due to the (truly) stateless nature of the HTTP protocol that underlies all web apps.

If you ignore this fundamental fact about web apps, you’ll end up building the proverbial useless piece of crap, like the one I just spent two weeks bandaging back into something resembling health.

One of the better ways (in theory) of dealing with this fact is the use of a stateful framework on top of the application. However, these are easier described than built. ;) I’m not personally familiar with any decent ones; the bulk of my Java web app experience has been Struts based, and I haven’t had time to explore any of the newer crop yet (though I’ve heard good things about ). However, I’ve seen some bad ones.

What does a tool like this need to provide? Well, it really shouldn’t constrain the user too much. One problem I’ve seen with a lot of attempts at stateful architectures is forcing the user down a particular page flow… if you haven’t gone through Pages A, B, and C, then you can’t get to D, and there’s no way you can pop back to A from C to fix something there without having to revisit B, and so forth. These, I think, are too restrictive. One good model I’ve seen is the install program used for RedHat Linux, where you can jump around the various tabs happily in any order (though some won’t be enabled until data is filled in, and other tabs will be disabled when a choice has been committed to).

And no, I’m not proposing a solution. I use this blog as a tool to help formulate my own thoughts, and right now my thoughts are that I’m not happy with the solutions I’ve looked at in the past. I need time to sit down and work out a way that I find personally better.

One strong point, however: don’t expect this to be easy. Solid, robust, and functional web applications are significantly more complicated than a single tier application, and more complicated than a fully stateful n-tier app (with a rich client). The only reasons they’re popular are:

* They solve a truly horrendous deployment problem common in a lot of organisations
* For internet apps, they’re very lightweight for clients (especially in terms of bandwidth). The ubiquity of the browser also provides a (rather shitty) lowest common denominator as well.
* CIOs like web apps, despite (or because) not knowing the drawbacks to them.

About these ads

One thought on “More on stateless web apps

  1. Mike Schinkel

    One of the key tenets of web apps is that they are stateless. And it’s one of their key benefits. It’s why they work so well and why they scale so incredibly well. What other architecture has achieved so much commercial success??? If you’ll open your mind and embrace statefullness, you’ll learn it myriad benefits and never look back. Studying “Representational State Tranfer” or “REST” is a great place to start.

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s