Stateful and Stateless Web Application

In this post, let’s discuss the application of stateful and stateless principles in web applications. This is the 4th post in this series about stateful and stateless design principles. Below are the previous three posts,

1. Being stateful and stateless
2. Stateful and stateless programs
3. Stateful and stateless protocols

If you haven’t read those yet, I suggest you have a quick look for better context. Especially the third one.

Stateful web applications

As discussed in the first post, an application is stateful when the application state is maintained.

For example,

• An e-commerce website might keep track of information about a product
• A social media might keep track of information about a user

Without maintaining state, it will be too difficult to obtain details about an entity in an application. A stateful web application can provide a meaningful and continuous session to a user only if it can develop a context by tracking the user interactions and maintaining a state. If you read my previous post about protocols, I have mentioned that HTTP is stateless. Web applications use HTTP for data transmission.

If HTTP is stateless, how can it help design a stateful web application?

As I mentioned above, to operate a web application in stateful mode, it needs to keep track of the user interactions and maintain a state. To do this, it should begin a session with the user. A session is a state maintained by the server. In case of a user login, server creates a session for the user where it maintains all the required information to serve any requests done by the user. This session is cleared when the user logs out. The server assigns the session with an unique ID to map it with an user. In any subsequent requests, the server retrieves the session data using this unique ID.

In the client side, the ID is stored in browser cookies. When a HTTP request is made, the ID is sent along with the request to the server. The server receiving the ID will load the session data. If the ID has expired or is invalid, it can request the user to login again and generate a new ID. The cookie can have an expiry time as well.
There are other ways to use the ID apart from cookies. It can also be an URL query parameter. Below is an example of query parameter.

https://www.heyiamanexample.com/?id=abcd1234

Note the query param id in the above URL. However, this should be used as an alternate to cookie if cookies is unavailable. Using URL params is unsafe as it is visible to everyone.

Example

Here are few examples of a stateful applications

• Without creating a session in Amazon, we cannot place an order or view list of our past orders. We will have to login first.
• Without a session in Facebook‘s server, we cannot edit our profile or view our friend list. We will have to login first.

Here is a fun example. A stateful application is like you booking a table for dinner in a restaurant.

• You call up the restaurant and ask for a booking.
• The restaurant gets your contact details and confirms availability.
• You visit the restaurant on time and authenticate yourself in by providing the contact details.
• The restaurant shows you the table allocated for you.
• You have your dinner, pay the bill and leave.

Here,

• The restaurant is the server.
• Your contact detail is the session ID.
• The table is your session data.
• You logout by leaving. This will terminate your session.

You can also call up the restaurant, use the contact details to cancel booking. Since you are identified by your contact details, the allocated table can be identified and freed.

Stateless web applications

Stateless applications are simpler than stateful applications since there are no sessions maintained in the server. Users are free to request a resource and the application can provide it only with the information available in the request. A static single page application like a blog post is a good example.

Example

Stateless web application can be a compared to any restaurant to which you randomly walk in. You don’t book a table and you simply enter the restaurant, find a seat, order, finish up eating, pay and leave. The restaurant will have no details about who you are.

Stateful vs Stateless Web Application

• Compared to stateful application Stateless web applications are easily scalable
• Stateless application will have lesser memory overhead compared to stateful application since a stateful application might need to store state like user session data. The more the number of user, the more the memory consumption.
• Stateless web application might require extra information from the user in some cases to retrieve requested data since it doesn’t have the user session.
• A heavier stateful application might require more CPU power when compared to a stateless application.

Well, that’s that about stateful and stateless principles in web applications. I hope this post was informative. If you find this post helpful, please share it with others and do support us 😁