Scalable Web by Stateless Development

Share this article:

Scalability is the ability to grow your web service to many users, it requires a special attention especially since recently there is a popular misconception that “if you host in the cloud, your application will be scalable”.  Well unfortunately this is wrong, “the cloud” hasn’t got any magical solutions, hosting in the cloud could actually make your web application slower and less scalable, if not developed in the right way. The good news is that sclability is not so hard to achieve, if you understand the basic concept of Stateless Web Programming:

Don't store any user state on the web server side

It means that you need to say goodbye to several “lazy programming” practices and in particular,  you should stop using the SESSION variables to store user state variables like user id, user name, permissions level etc. I will explain below the details and how to implement the stateless web development, this is fairly easy

Why stateless is scalable?

“stateless” is scalable since the best way (so far) so increase volumes of service would be in the shape of distributing the databases, instead of trying to distribute the web service. In the high level, most web applications have got two main components: a web server, and a database server. The web server (usually Apache, IIS, Nginx etc) is serving the HTML content, and the databases are storing long term data like user information and content. The HTTP protocol, by design, is stateless – each HTTP packet requested by the browser is independent from the other packets (that’s why in some cases, on the same web page, different elements get served by different routes) – however – webservers can identify a browser session even if the user is flicking between different web pages, actually – the browser session stays alive, as defined in the servers configuration variables, for a certain time even if the user completely leaves the site. So if the user session could be identified by a web server, the next level is to define “session variables” which are stored on the web server. Developers are using those web server session variables to store some “rapid access” information, for example, if a user logged in to the system, the server session variables can store the fact that the user has got permission to access a specific site functionality. Now, imagine that we try to scale this web app and host it on several servers…. and that a user named Suzy is starting her session with SERVER NUMBER 1 and then flicks to another page which is now served by SERVER NUMBER 5. Obviously SERVER NUMBER 1 and SERVER NUMBER 5 has got different session variables, which means that SERVER NUMBER 5 won’t know that Suzy has got a permission to view that specific page. IF the application was designed without using the session variables, it would be scalable.

How to develop stateless app?

So the solution is not to store any states on the web server side, but to use the client side, or the databases (or both) to store it.  This can be done in many ways, if we consider the above example, the developers could have:

  1. Once the Suzy logged in, store a cookie in Suzy’s browser. The cookie will contain Suzy’s User ID, and lets call this cookie “cookie_user_id
  2. Store all Suzy’s user permissions, like which pages she is allowed to access, on the database side
  3. For each hit to the webserver (any click / ajax request / form request) send the value of cookie_user_id with the request
  4. For each request served by the web server, read the permissions table by using the value of cookie_user_id to query the right tables row

 

Databases, unlike webservers, are easily scalable (I will devote a new blog for that subject in the future). It means that if you host a stateless application and scale it by building several web servers and several databases servers, the stateless conditions will guarantee that your web app will continue to work properly

All the best 🙂

Eran

Inspired by: https://www.cleverquantum.com and Quantum Computing Blog

 

 


Share this article:

Comments

comments

You may also like...

Leave a Reply

Your email address will not be published. Required fields are marked *