A subscriber receives messages from a message queue. It listens on the same Redis channel, or for the same NATS subject, that a publisher uses. The two components do not communicate directly: each works with the queue, so a subscriber can keep listening even when no publisher is active. section 21.1 section 21.2
Watch a Redis channel
With Redis and a publisher running on the ch21 Docker network, run `docker run -it --network ch21 --name subscriber diamol/redis-cli:2e SUBSCRIBE channel21`. The publisher sends `ping` every five seconds; the subscriber prints each message it receives. Press Ctrl-C to stop listening. section 21.1
Starting a subscriber late matters. Redis and NATS subscribers receive messages published after they begin listening; messages published with no subscriber are dropped. In the to-do app, the web page can publish a new-item event successfully while the list remains empty, because nothing is listening to process that event. section 21.2
# run a subscriber listening for "events.todo.newitem" messages docker run -d --name todo-sub ` --network todo-list_app-net ` diamol/nats-sub:2e events.todo.newitem # check the subscriber logs: docker logs todo-sub # browse to http:/./localhost:8080 and add some new items # check that the new item events are published: docker logs todo-sub
Run the NATS subscriber for `events.todo.newitem`, add a new to-do item, then check `docker logs todo-sub` to verify that the event arrived. section 21.2
A subscriber can also perform work rather than just log messages. An audit handler and save handlers listen for the same new-item event: the audit handler receives a copy, while another copy goes to one save-handler container. This lets a new feature respond to an existing event without changing the web UI. section 21.4
