The Moving Parts of a Channel

Before we implement our own Channel, let’s take a look at the moving parts that make up a Channel.

The pieces of a Channel

We often talk about Phoenix Channels as if each one is a single, monolithic entity working independently. In fact, there are a number of moving parts acting in harmony across multiple layers that make Channels work as well as they do.

Let’s take a quick look at the most important ones to get a better feeling for the whole.

The Channel module

The Channel module is the tip of the iceberg, which is the most visible part that we will interact with. It’s a custom Behaviour defined within Phoenix. The Behaviour specifies that we define a join/3 callback for allowing clients to join a specific topic as well as multiple handle_in/3 callbacks to match, handle, and respond to messages sent from clients.

Socket

Phoenix.Socket is also a custom Behaviour defined in the Phoenix application. It establishes and maintains the connection between clients and a Channel. The socket also keeps track of which transport method the Channel uses.

Socket is also a struct that defines and holds the connection’s state. It’s analogous to the connection struct in the stateless MVC parts of Phoenix.

Transport

Channels rely on protocols to move messages between the client and the server. That’s what the transport layer is for. Phoenix ships with two types of transports built-in: WebSockets and long polling.

Socket.Transport is also an API for building transports. It’s possible to create our own custom transport layer for whatever protocol we like by following the Socket.Transport API.

Phoenix PubSub

Channels are very flexible in the way they allow us to route messages from the channel to clients. That’s handled by a separate package called phoenix_pubsub. PubSub is short for “publish and subscribe”, and is a way for clients to register with a channel (subscribe) to get published messages sent to them. The way clients subscribe is via the join/3 callback function.

Presence

Phoenix Presence is an incredible piece of technology. It uses data types from cutting-edge computer science research—conflict-free replicated data types (CRDTs)—in a web framework, we can use right now.

Presence solves the hardest and most extreme edge cases in keeping track of clients in channels—multiple nodes in a distributed cluster, clients connected on multiple devices, and anything going wrong with either the network or the clients. Presence solves these problems in a mathematically provable way.

Presence does not only solve the original problem of channel membership. It also promises to be useful for service discovery, process discovery, and anything we need to track on BEAM nodes distributed across a network.

Client code

Channels on the server are only half the story. We need clients to complete the picture. Channel client packages exist for several different languages and platforms. We’ll use the JavaScript client that ships with Phoenix as we write functions directly in a browser window’s JavaScript console.