Observer Vs PubSub

Observer Vs PubSub

Let’s delve into Observer design Pattern and Publish Subscribe pattern. At a high level, both these are design patterns to communicate state changes or notifications to a listener. We didn’t originally plan to write on this subject. But, working on the dashboards, we realized we had to use both these patterns and wanted to write this blog about the differences between these 2 patterns and how the use cases dictate using one over the other. To start off, let’s have a graphical representation of both these patterns.

Publish-Subscribe Design Pattern

The publish–subscribe is a messaging pattern where senders of messages (a.k.a., publishers), do not program the messages to be sent directly to specific receivers (a.k.a., subscribers), but instead categorize published messages into classes without knowledge of which subscribers, if any, there may be. Similarly, subscribers express interest in one or more classes and only receive messages that are of interest, without knowledge of which publishers, if any, there are. Publishers are loosely coupled to subscribers, and need not even know of their existence. With the topic being the focus, publishers and subscribers are allowed to remain ignorant of system topology. We are using this pattern on the dashboard when we get a notification through the Web Socket. The messages are categorized into topics. Dashboard widgets that listen to individual topics can either refresh the corresponding table or display a message to the user about the object state change.

Observer Design Pattern

The observer design pattern is a software design pattern in which an object, called the subject, maintains a list of its dependents, called observers, and notifies them automatically of any state changes, usually by calling one of their methods. This type of implementation is considered “tightly coupled”, forcing both the observers and the subject to be aware of each other and have access to their internal parts, creating possible issues of scalability, speed, message recovery and maintenance (also called event or notification loss), the lack of flexibility in conditional dispersion, and possible hindrance to desired security measures. This is the easiest implementation and is widely used in today’s web applications. However, because of it’s tight coupling, we prefer Publish-Subscribe over Observer Design pattern.[/vc_column_text][vc_column_text]

At BundleN, we experiment with stack combinations on our own time.

For potential clients interested in this stack, we can always give a demo of what we have up until that point of time. You can reach us at sales@BundleN.com

For more details contact sales@BundleN.com

Here is the latest about our Angular + Java project.

Task

Publish Subscribe for Events

Task Details

Add ability to dashboard widgets to refresh or get updated data based on Publish-Subscribe for events

Task

Back end object for notifications

Task Details

Develop a back end object for communicating notifications with the front end application.

User Roles Back end End points and UI, Every organization deals with lot of roles. Let’s get some back end end points and also throw in a UI page for an admin to handle roles. Most companies have an LDAP we can use for roles. We can have LDAP integration at a later time.

Roles API End Point

Social Login using Google

Social Login using Facebook

Forms

Form Validation

Logs

Security

sales@BundleN.com