Chapter 10
Using Channels

If you dabbled in Phoenix before buying this book, at this point you’re probably wondering why we’ve come so far and barely mentioned channels. The truth is that for the interactive applications we care about the most, channels are simpler to build so there’s less to talk about.

Think about everything you’ve learned so far. Up until now, a browser made an isolated request and Phoenix delivered an isolated response. We had to spend plenty of time on pipelines and code organizational tools that let you do everything necessary to tie an individual user to each request and remember the exact state of the conversation. You know it well. A browser makes a request and the web server returns a response:

We build applications that way for a good reason. Each request is stateless, so it’s easy to scale. When the programming language simply can’t keep many connections around, it makes sense to do a little extra work so the web server can treat every request as a new one.

Sometimes, though, that programming model has too much overhead for the types of applications we want to build. Programs must be longer, programmers must work harder to reason about them, and the server has to work harder to process them.

This chapter will focus on the highly interactive problems that Phoenix solves so well. These problems don’t lend themselves to a request/response flow. Think live chats, Google Maps, kayak.com, and twitter.com. In that world, a single client on a page connects directly with a process on the server called a channel, like this:

It looks simpler because for the programmer it is simpler. Since Elixir can scale to millions of simultaneous processes that manage millions of concurrent connections, you don’t have to resort to request/response to make things easy to scale or even manage. A client connects to a channel and then sends and receives messages. That’s it.

It’s now cool again to have applications where the clients and servers just, you know, talk directly to each other. That’s why this chapter is much shorter than the request/response paradigm covered in Part I, and it’s also why Phoenix is such a big deal.