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.
Publish Subscribe for Events
Add ability to dashboard widgets to refresh or get updated data based on Publish-Subscribe for events
Back end object for notifications
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