Publish/Subscribe

Introduction

This article will explain to newbies what Emitter is, what it can be used for and what the advantages are of using Emitter. If you are an expert in publish subscribe systems already you might want to scroll down to only read the summary at the end of this page. The next section explains Emitter by first explaining properties of direct one-to-one communication. Next it will explain benefits of using Emitter for one-to-one communication instead of using traditional direct one-to-one communication. When this is clear, an explanation is given of how Emitter can be used for other forms of communication, like many-to-many communication and push notifications. Finally conclusions are drawn and relevant links are provided.

Traditional direct one-to-one communication

If multiple people/devices need to communicate online, this can be done with direct one-to-one communication. For direct one-to-one communication, the following conditions must be true:

  • The devices should know the location of each other.
  • The devices should both be online at the same time.
  • The devices should be available for this communication (should not be blocked by other communication actions).

Classic One-To-One Communication

One-To-One Communication

Benefits of using publish subscribe systems for one-to-one communication

This form of traditional direct one-to-one communication could be handled by using a publish-subscribe system. In such a system none of the three above conditions need to be true. There is a decoupling in space (knowing locations of the other device), in time (being online in the same time) and in availability (not being blocked) of devices. This decoupling is done by introducing a broker, see above image.

The publishing party publishes its message(s) to the broker. The broker is typically a server or a mesh of servers that is always online. The publisher should give each message a topic (also called a channel).

The receiving party subscribes to the related channels. Whenever the subscriber is online and the broker has messages that have not been read by the subscriber, the broker pushes the messages towards the receiver. If the subscriber is not online at the moment a message is published, the broker simply stores the message and sends it to the subscriber as soon as it comes online. All the intelligence is inside the broker, you could see this as a black box. You can use Emitter without any understanding about how the broker technically functions. The publisher and the subscriber only need a simple API call to publish messages or to subscribe to channels to receive messages.

emitter.publish({
    key: ...,
    channel: "newbie_channel",
    message: "Hello, World!"
})

Note that it is possible to create multiple channels. This also makes it possible for one device/user to be both a sender and a receiver.

emitter.subscribe({
    key: ...,
    channel: "newbie_channel"
})

So there you have it. This is the main piece of code you need to do be able to send and receive messages using Emitter.

Note that you can use the cloud version, but you can also install emitter on your own server(s) by downloading the source code from Github.

Many-to-many communication using publish subscribe systems

The previous section showed how Emitter could be used to do simple one-to-one communication. This already gave the benefits of decoupling in space, time and availability because:

  • Senders do not need to know whereabouts of receivers.
  • Senders can even send information to receivers if they are not online, they will receive the message at a later stage (at least, if that is how you set things up).
  • If the receiver is blocked, the broker will deliver the message as soon as the receiver is available.

Now you understand how to use Emitter for one-to-one communication, we will explain how to use Emitter for one-to-many, many-to-one or many-to-many communication.

We’ll start with one-to-many communication. Compared to the previous example nothing changes for the publisher. The only difference between one-to-one and one-to-many communication is that there are multiple receivers that subscribe to the same channel. An example of one-to-many communication is a news website that sends push notifications to multiple users if there are new articles. 

One-To-Many Communication

In case of many-to-one communication there are multiple senders that publish over the same channel and there is one subscriber to that channel. An example of many-to-one communication is one server that automatically receives all the error messages of all users of a certain application.

Many-To-One Communication

Many-to-many communication is a system where multiple senders publish over the same channel and multiple receivers subscribe to the same channel. An example is a group chat where all users send and receive over the same channel. 

Many-To-Many Communication

In all images in this section each device/user was either a publisher or a subscriber. In practice this does not need to be the case. Entities can both be publishers and subscribers. You are free to create as many channels as you want and each entity can publish and/or subscribe over any number of channels.

Summary

Emitter is not more complex to use than traditional direct one-to-one communication. When using Emitter you’ll have a broker and APIs to connect to the broker. There is no need to understand how the broker works in detail in order to use Emitter, you can just see it as a black box. Benefits of using Emitter are that publishers and senders do not need to know each other’s whereabouts, do not need to be online at the same time and do not need to be available at the same time. Emitter can be used for one-to-one, one-to-many, many-to-one and many-to-many communication.

You can use the Emitter cloud, but all source code is also freely available on Gitbub, so you can even create your own cloud or single-server broker. Emitter will take care of all load balancing and all other things you do not want to worry about. In a multi-server environment you can even make sure Emitter is set up in a redundant fashion, ensuring that users will not notice anything if one server is down.