PubSub

Selecting a topic name

A carefully selected topic name is vital for the scalability and behavior of an application. For instance, a public Channel providing inventory updates to an e-commerce storefront could be implemented in a variety of ways:

• inventory: This topic does not delineate between different SKUsStock Keeping Units.
• inventory:*: This topic delineates between different item SKUsStock Keeping Units with a wildcard.

If an overly broad topic is selected, such as inventory, then an inventory change to an SKU is broadcast to every connected client, even if they are not viewing the item. A narrower topic such as inventory:* would lead to more connected topics (one per viewed item) but means that outgoing data could be held back from clients that aren’t viewing a particular SKU.

In this example, we would select a solution based on our business needs and tolerances. The single inventory topic would involve simpler code to implement, but it would use more bandwidth. It would also expose every inventory update in a way that allows adversaries to index the store quickly. The wildcard topic provides more performance optimization possibilities at the cost of more connected topics and additional client code. It would still be possible to watch for all inventory updates, but this would be significantly more work.

The battle between the scalability of performance and maintenance is constant; the best solution often depends on decisions specific to a business. Now that we understand the Channel structure, we’ll move into how data is delivered to and from the client.

PubSub

Phoenix.PubSub (publisher/subscriber) powers topic subscription and message broadcasting in our real-time application. Channels use PubSub internally, so we will rarely interact with it directly. However, it’s helpful in understanding PubSub because we’ll need to configure it properly for our application to ensure performance and communication availability.

PubSub is linked between a local node and all connected remote nodes. This allows PubSub to broadcast messages across the entire cluster. Remote message broadcasting is important when we have a situation where a client is connected to node A of our cluster, but a message originates on node B of our cluster. PubSub handles this for us out-of-the-box, but we need to make sure that the nodes have a way to talk to each other. PubSub ships with a pg2 adapter out-of-the-box. There is also a Redis PubSub adapter that allows PubSub without having nodes clustered together.

PubSub is used to call the HelloSocketsWeb.Endpoint.broadcast/3 function. Let’s see an example of this and how it can push messages from our application to our Channel. Without changing our application, we can do this by issuing commands directly in iex. We’ll start our server using iex for many examples throughout the course because it allows us to test our application and see results quickly.