• Paul Butler
The web browser has become the de facto delivery channel for new application software. Developers are targeting the browser for increasingly ambitious apps, from video editing to mapmaking and data tools.
It’s tempting to lump all browser-based software together as “web apps”, and people who build them as “web developers”. But the way developers are building desktop-like experiences in the browser has been diverging from the way that web-native applications (like blogs and social media sites) are built.
One difference that’s emerged is a pattern that we call session backends.
In a traditional web architecture, the backend layer consists of a pool of stateless, interchangeable servers. Every request sent from the frontend to the backend contains all the information needed to fulfill it, or at least, contains enough context for the server to locate that information in a database.
This approach is great for apps that are essentially just a database with a UI and some business logic, because state changes can be performed in isolation using only a tiny piece of the entire program state. For example, a calendar app does not need to read your entire calendar into memory to change the date of a meeting; it just sends an UPDATE query to its database.
As more complex applications migrate to the browser, this approach breaks down. Instead of a calendar, consider a code editor (IDE). The program state of an IDE includes, in addition to your code, various data structures derived from that code to enable low-latency auto-complete and linting. These data structures are updated as frequently as every keystroke, and re-creating them from scratch each time would defeat their purpose. A stateless backend won’t do.
The options available to a developer at this point fall into three general approaches:
The third approach is what we call session backends. Of the three, it is the most difficult to shoehorn into a traditional web architecture, where statelessness is axiomatic. In spite of that, it’s quietly started popping up in applications that reach the limits of the other two approaches.
Examples of session backends in the wild include:
This looks like a set of disconnected niches, but we believe that as browser-based applications compete on features and performance, session backends will become a building block for applications in every category that strive for a desktop-like experience.
Because session backends break the statelessness assumed by the traditional web stack, they’ve been out of reach to developers who don’t have a dedicated infrastructure team to architect and maintain them.
We’re trying to change that with the release of Plane, our open-source (MIT-licensed) platform for session backends.
With Plane, you provide your backend as a container image (aka Docker image), and Plane gives you a private HTTP API for “spawning” new instances of that backend in your cluster. The API returns a URI, which can then be used to open HTTP connections directly to that new backend, directly from your frontend code. Plane monitors activity to the backend process, and shuts it down after a period of no connections. Here's a demo.
As a result of this architecture, Plane is unopinionated about how you build your app, as long as it speaks HTTP (with support for WebSockets).
Plane is still under rapid development, but we’re eager to get feedback from developers pushing the envelope of browser-based applications.
Check out Plane on Github.
Jamsocket is the hosted version of Plane. You can use Jamsocket to start session backends on our managed cluster and never think about servers.
If you prefer to run backends on-prem, you can use Jamsocket as a managed control plane to run backends on your own servers with our bring-your-own-compute model. We manage scheduling, DNS, certificates, and observability so you don’t have to.