The pub/sub (publish/subscribe) function enables senders (publishers) to publish messages on "channels" and enables receivers (subscribers) to subscribe to the channels and receive messages when they are sent. The "hello world" application of pub/sub is often a chat application, but let's defy tradition and use pub/sub in an IoT scenario instead.
In our scenario, we want to be notified when our garage door is opened or when it is closed. To accomplish this, we connect a Raspberry Pi to a garage door sensor using an Arduino, Particle Photon, XBee, or some other means. We then run a Node.js application on the Raspberry Pi to publish the garage door open/close events, and we run a Node.js application on another system to receive notification when events occur.
For the sake of our demo, we will run both the publisher and subscriber on the same system, and this system will also host the Redis server.
Let's get started and create a Node.js console application called
subscriber.js and add the following contents:
Our subscriber utilizes a handler in line 5 to receive incoming messages from the publisher.
In line 11, we subscribe to the
garageDoor channel and wait to receive events. When invoked, this program will continue to run until the user halts its execution with Ctrl+C.
Next, we create a Node.js console application called
publisher.js to publish our garage door open/close events as they occur:
We use a sleep function in line 7 to introduce delay times in the program so we can simulate gaps and publish events at varying times.
In line 13, we publish our first event on the
garageDoor channel (after a 4 second delay) to let our subscriber(s) know that the garage door has opened.
In line 16, we publish our second event (7 seconds later) to indicate that the garage door has been closed.
Now it's time for the moment of truth:
Open a terminal window and issue the following command:
$ node subscriber.js
Launch a second terminal window and fire up the publisher application:
$ node publisher.js
Watch the terminal hosting the subscriber application carefully and expectantly.
You should see the following output after 4 seconds and an additional 7 seconds have elapsed:
Subscribed to 1 channel. Listening for updates on the garageDoor channel. Received the following message from garageDoor: opened Received the following message from garageDoor: closed
If you really want to go for the gusto, open another terminal window and start a second subscriber program. Re-run the publisher program, and you will see both subscribers receiving the published messages. How awesome is that?
As expected, the answer is "it depends". Pub/sub work wells in a variety of contexts. Please be aware, however, that subscribers are not guaranteed to receive messages. For example, if the subscriber is experiencing network connection issues or is not able to read the messages fast enough, the data from the publisher will be lost.
If we were uploading our garage door open/close events to a cloud historian and could afford to miss any events, we would not want to rely on Redis pub/sub to relay the events to the cloud. A better approach would be to buffer the events in a Redis list, and rely on our subscriber to empty the Redis list. During those times when the subscriber was unavailable, the events would continue to buffer in the Redis list for the subscriber to retrieve and send to the cloud at a future time.