A History of State

Before we move on to where we’re going, though, let’s see where we’ve been.

States and transitions

Early client-server applications were stateful. Clients connected to the server and stayed connected while they passed messages back and forth. We can think of mainframe applications with dedicated terminals as clients.

That worked well, but it meant that the number of possible clients was limited by system resources like memory, CPU, and the number of concurrent processes the system could support.

The web gets around these limitations because of HTTP’s nature. When a client makes an HTTP request to a server, it must supply all the data the server will need to fulfill that request. Once the server sends its response, it forgets everything it knows about both the request and the client.

This request-response cycle has been critical to the success and scaling of the web. It requires fewer system resources to handle many more requests because the server doesn’t need to keep track of anything once it sends a response. This allows applications to use less expensive shared pools for resources like database or mainframe connections instead of more expensive dedicated resources for each client. Applications can manage other resources like threads and memory the same way.

HTTP shed resource costs, but picked up others along the way. It’s impractical to pass all the states a complex application needs. Instead, servers store that state in a database. The clients pass along only enough information for the server to fetch that data to fulfill the request. If the request involves any change in state, the server needs to write those changes back to the database. These trips to and from the database add latency. Modeling a domain for a database adds unnecessary complexity.

As developers, we pick up the tab for these added costs in terms of extra code to write and maintain. There is also an extra cognitive load when reasoning about our applications.

Change in web development

As applications grow and traffic increases, these costs begin to add up. At a serious scale, they can become prohibitive. So, developers look for ways to get around them.

We’re at the beginning of a sea change in web development. We’re seeing the return of stateful servers with persistent client connections. Modern hardware provides abundant system resources. Elixir provides more than enough power and concurrency to handle the application state and persistent connections at scale. Phoenix Channels make writing those persistent connections a breeze.

With stateful applications, we no longer have the luxury of a clean state with every new request. We have to manage the state over time and make sure it remains consistent. We need to understand the stages an application can go through and handle the transitions between them. We need to ensure that events in the system are consistent with the stage in which the application is.

The front-end world

Front-end JavaScript developers have already walked the path from a mostly stateless to a stateful environment. With the rise of Ajax, a front-end tool used to communicate with the back-end, requests a number of years ago, front-end web applications could fetch data outside the normal request-response cycle. They could update the DOMDocument Object Model without a full page reload that would wipe the state clean.

The rise of Ajax opened up incredible possibilities in user interactions. Web applications became as complex and interesting as desktop apps—map applications, email, and office suites. With the vastly increased time between page reloads, the browser suddenly became a stateful environment, and developers quickly found that they needed strategies to manage the state.

The JavaScript world is still grappling with this shift. The community is continually inventing new solutions to ease the difficulty of handling state – frameworks, data binding libraries, promise libraries, generators, and more. The sheer number of solutions out there and the speed with which they hit the ecosystem creates a very real sense of fatigue.