Explore the Route

A plan to move forward

Welcome! We’re about to go exploring, and it’s going to be a blast. We’re going to do what many of us say we love most. We’ll play with new languages, experiment with new techniques, and expand our understanding of writing software for the web. Whenever you go exploring, it’s important to have a map, a good idea of where you’re headed, and a plan for how we’ll get there. That’s what this chapter is all about.

Many early client-server systems were stateful. Servers kept working state in memory. They passed messages back and forth with their clients over persistent connections. Think of a banking system with a central mainframe and a dedicated terminal for each teller. This worked because the number of clients was small. Having fewer clients limited the system resources necessary to maintain those concurrent connections.

A little about web interfaces

Tim Berners-Lee invented a new client-server system called the World Wide Web. The web is an incredibly successful software platform. It’s available almost everywhere on Earth, on virtually any device. As the web has grown and spread, so has HTTP. HTTP is a stateless protocol, so we think of web applications as stateless as well. This is an illusion. The state is necessary for applications to do anything interesting. However, instead of keeping it in the memory on the server, we push it off into a database where it awaits the next request.

Offloading a state to a database provides some real advantages. HTTP-based applications need to maintain temporary connections with clients only until they send a response. So, they require far fewer resources to serve the same number of requests. Most languages can’t muster the concurrency necessary to maintain enough persistent connections to be meaningful for a modern web application.

Stateless UI

Going “stateless” has let us scale.

However, statelessness comes at a cost. It introduces significant latency as applications need to make one or more trips to the database for the data to prepare a response. It makes the database a scaling bottleneck, and habituates us to model data for databases rather than for application code.

Elixir offers more than enough concurrency to power stateful servers. Phoenix Channels provide the conduit. A single Phoenix application can maintain persistent Channel connections to hundreds of thousands or even millions of clients simultaneously. Those clients can all broadcast messages to each other, coordinated through the server.

While processing those messages, the application remains snappy and responsive. Elixir and Phoenix provide a legitimate alternative to stateless servers capable of handling modern web traffic.

The stateful app in Elixir

We’re about to explore this new opportunity with a stateful application written in Elixir and a persistent Phoenix Channel ready to connect it to any front-end application.

We’ll do this by building a game called “Islands.” It may not be a top download on our favorite gaming platform, but it will be fun to play. Most importantly, we’ll learn a lot by building it. Game developers have always pushed the web to the extreme. They’ve had to approach problems in novel ways to meet their performance needs. We’ll be rethinking our approach as well. What we’ll learn will help us solve everyday business problems in radically improved ways.

We’re going to tackle the Islands game in distinct parts. We’ll start with a stateful game engine written in Elixir and then we’ll layer on a web interface with Phoenix. We’ll stop just short of building out a full front-end application. There won’t be any new territory for us to cover.

We will include the code for a demo front-end application. This will allow us to play a demo game locally on our machine.

We’re going to build Islands in a way you might not be used to. So, let’s get an idea of what lies ahead.