Over the past few weeks, I've been delving into the trending design patterns in frontend development. I've covered the Singleton, the Facade, the Observer, and most recently, the Pub Sub Pattern Design.

The last two articles focused on the Pub/Sub and Observer patterns. While these two patterns share some conceptual similarities, I thought it would be interesting to explore their differences. Hence, this post.

Main difference

Both of these patterns have a concept of publishing something and subscribing to an observer, right? So what’s the difference?

The Observer pattern solves this by allowing the Client to attach itself as an Observer to the Store. When the iPhone arrives, the store notifies all attached Observers. While in the PubSub application, it publishes an event/data to an event broker, and then the subscribers listen for it. The publisher is unaware of its observers.

In our Client-Store scenario, the event broker of the PubSub application could be like a marketplace. It would need to keep track of product availability in the store. When a new iPhone arrives, the marketplace system would register this event and notify all subscribers (customers who expressed interest in the iPhone) by sending them an email or a push notification.

Observer patterns are mostly used when you want different parts of a single application to share data with each other, usually in real-time. In this case, the entity providing the data is aware of who is receiving it.

On the other hand, the Pub-Sub pattern allows data to be shared across multiple applications. This usually happens asynchronously but can be made synchronous using specific SDKs, like the SuperViz Real-time Data Engine. In this pattern, the one sharing the data doesn't know who's receiving it - they just put it out there for anyone interested.

The main difference is that the Pub-Sub pattern supports a more decoupled architecture, where the data sharers and receivers can work independently from each other. This is not the case in the Observer pattern.

Use Cases for Observer Patterns

Observer Patterns are often used in GUI development, where one part of the application (the button) needs to notify another part of the application (the click event handler) when a certain event (the button being clicked) occurs.

Use Cases for Publisher Subscriber Pattern

In the context of frontend development, Publisher Subscriber Patterns can be instrumental. For instance, in a complex web application, different components may need to exchange data in real-time, like in a chat application, tracking the GPS of a taxi, or even real-time stock market data updates. These are situations where different components need to stay updated without having a direct relationship with each other.

Let me know in the comments area if you have other scenarios where the Observer or the PubSub is helpful.

Real-time Data Engine

If you're building a web application that requires real-time data sharing and communication, SuperViz is an SDK tool worth considering. It offers a real-time collaboration and communication SDK and API, designed for developers building real-time web applications.

Using SuperViz, you can create a room with several participants. When publishing an event, it will be broadcasted to all the participants in the room who are accessing it through different devices and networks. This means that any updates made by one participant will be reflected in real time across all devices, providing a seamless and collaborative experience.

SuperViz provides the infrastructure necessary to build real-time, collaborative applications. This includes the ability to catch these events on your backend using webhooks, as well as to publish an event with a simple HTTP Request, to name a few features.

You can easily test it with our open-source sample codes that run with a glance.