What is state and why does it matter?

State /stāt/

The particular condition that something is in at a specific time

– Dictionary.com

State can be a nebulous term.  In computer science, we talk about a plethora of state: application state, resource state, session state, router state, stateless servers… yadda, yadda, yadda.  Why do you care?  You care because how we as developers think about state and use state in building your web applications affects your user experience.  State decisions play a role in the speed of retrieving resources, the user experience of invalid form input errors, and up-to-date product listing information to name a few.  This blog post will attempt to shed light in the understanding of state as it applies to building web applications so you and your developers can better identify the development choices necessary to achieve the user experience you are after in building the next iteration of your web presence.  We will take a look at Application State, Resource State, and Session State to provide a few examples.

Application State

Application State (also known as Program State) represents the totality of everything necessary to keep your application running.  When we refer to application state we are normally referring to the state of the program as it exists in the contents of its memory.  But what does that mean practically?  How am I to understand that?  It helps to think in extremes.  What happens to information and functionality core to your application if a server goes down and restarts?  You lose whatever was residing in memory.  This is one of the reasons why in web development we often use stateless resource controllers which disseminate the information necessary to the running of your application in a way that does not rely heavily on holding data for retrieval on the server’s memory.

Resource State

Resource State refers to the state of the resources being stored on the server.  These can be files, images, database records, etc.  Resource state changes as resources are added, modified, or deleted.  One of the great advancements of the past twenty years in web development has been the adoption of the REST Architecture which is a stateless way of working with web resources.  Each request in REST explicitly communicates its intended action on the resource and passes with it the information necessary for achieving that action.  REST works like this.  Say you want all stories in a database.  Your request would look like GET /stories.  Say you wanted to create a new story.  Your request would look like this POST /stories.  Say you wanted to go retrieve that story.  Your request becomes GET /stories/1.  You get the drift. 

But now we are in a world where even REST is being stretched.  Applications are becoming so laden with information that making multiple http requests to retrieve the resources using traditional REST endpoints is becoming cumbersome on performance. 

Enter GraphQL.  GraphQL moves away from the conceptual model of “resources” which has dominated the past decades of peoples web experience and instead favors an entity graph as its core concept.  As we work with data more and more in the present iteration of the web filtering and relationships mean more and more to the user experience.  In GraphQL, you are able to retrieve in one GET request very particular information using arguments to your GraphQL endpoint that would take multiple round trips to acquire using traditional REST.

Session State

Session State keeps track of user interaction during a browser session.  It holds the status of the communication between the client and the server and now we use it broadly to describe that state that relates to a session ID and http cookies.  It is session state that remembers the page you were last on, like holding your cart items so they are still there if you close your browser and navigate back to where you were shopping before, and informs the website as to whether or not you are authorized to view a specific page.

Closing Thoughts

Understanding state matters.  Knowing where your application will hold information and what will keep the user’s experience as smooth as possible resides with decisions around state.  State decisions can create a more resilient web application, quicker resource retrieval, and need to be factored into security considerations.  The next time you are building a new version of your website or launching a new web application engage your developers on what you should be considering in enhancing your user experience in effectively using state.