🍻 Pub Sub 🍻
Published: 2019-12-12 08:28:49

A terrible pun intended :point_up:

Have you ever joined a mailing list or followed an account on social media? Have you ever subscribed to a channel on YouTube?

If your answer is "Yes!" to any of the questions above then congrats! :tada: You pub-subbed.

> Pub-subbed [ :loudspeaker: _puhb-suhbd_ ]
> :white_circle: _verb_
> Becoming a part of publish-subscribe messaging system.
> Creating a publish-subscribe messaging system.
> "He *pub-subbed* his way out of the problem."

---

![Mailboxes]
(https://thepracticaldev.s3.amazonaws.com/i/mocfwrq0lwvsk0txk3hs.jpg)
<figcaption>More accurate image to represent pub/sub</figcaption>

**What is pub/sub?**

Pub/sub in its full form publish/subscribe is a messaging pattern. It is a way for different components of a system to notify each other and it's a great alternative to polling.

In this pattern there are - you guessed it - publishers:outbox_tray: and subscribers:inbox_tray:. In addition to them there are messages:email: and channels/topics :mailbox:. 

 :100: Publishers can have any amount of subscribers
 :male_detective: Publishers don't have to know about their subscribers
 :arrow_left: Publishers send messages to channels or topics to which subscribers can subscribe

---

 :100: Subscribers can subscribe to any amount of publishers
 :male_detective: Subscribers don’t need to know who the message comes from
 :arrow_right: Subscribers receive messages from channels or topics to which publishers send messages


**What are the advantages of pub/sub?**

:white_check_mark: Decoupling/Loose coupling
 * Since neither the publishers nor the subscribers have to know about each other pub-subbing helps with the decoupling of system components.

:white_check_mark: Scalability
 * When number of subscribers or channels/topics increases adding new servers to the system helps with dealing with the increased load.

:white_check_mark: Asynchronicity
 * Since publisher sends its messages to a channel or topic it doesn't have to wait for a subscriber to receive the message. And since the subscriber receives messages from a channel/topic it doesn't
have to wait for a message. In fact it doesn't have to be up when the message was sent.


Do all these remind you something? _Hint: The answer is a design pattern._

.
.
.
.

The answer is: Observer!

Pubsub is similar to Observer design pattern of Gof :ok_man:.

**:lock: Which problems does Observer solve? :lock:**

_From Gof_

- How can a one-to-many dependency between objects be defined without making the objects tightly coupled?
- How can an object notify an open-ended number of other objects?

**:key: How does Observer solve these problems? :key:**

_From Gof_

- Define Subject and Observer objects 
 - Subject -> Publisher and channel/topic
 - Observer -> Subscriber
- When a subject changes state, all registered observers are notified and updated automatically
 - Subject changes state -> Publisher sends a message to channel/topic
 - Observers are notified and updated -> Subscribers are notified and updated

**Similarities**

- Just like in pubsub, in observer the subjects don't have to know about their observers and vice versa.
- Just like in pubsub, in observer the subjects can have any amount of observers and vice versa.
- Just like in pubsub, subjects and observers are loosely coupled.
- Just like in pubsub, observers can be updated asynchronously.

----

If you're not sick of me associating things, both observer pattern and pub/sub messaging reminds me of the mailing systems in human world :man_shrugging:. It's really cool to see concepts from computing world resemble human world :computer: :earth_americas:.

----

###### Cover Image: Photo by Mary Rebecca Elliott on Unsplash
###### Body Image: Photo by Mathyas Kurmann on Unsplash