webhook vs publisher and subscriber

Question

I came across the concept called webhook and publisher/subscriber. In webhook the third party application send the information whenever the updation happened in the depend application, thirdparty will send a HTTP post request to the mention URL for your application, and In publisher and subscriber, subscriber will register the topic and publisher write on that topic then registrar(like the third party) will send the information to the subscriber based on the topic subscribed.

both are similar or difference?

I am confused can anyone give solve to this?

Answer 1

Well, conceptually both of these methods were used to notify a client when an event occurs. But practically I would use them in two different scenarios. The webhook (from Wikipedia):

A webhook in web development is a method of augmenting or altering the behavior of a web page, or web application, with custom callbacks. These callbacks may be maintained, modified, and managed by third-party users and developers who may not necessarily be affiliated with the originating website or application. The term "webhook" was coined by Jeff Lindsay in 2007 from the computer programming term hook.

The webhook approach is relevant when you want to communicate asynchronous changes or updates between a third party to your backend server.
That means that the 3rd party needs to register the webhook address for each client and trigger an http request with the information needed to be communicated.
Some of the considerations using webhook is that the failure handling in case the webhook address isn't responding or for any given temporary failure, the retry responsibility and handling is done by the publisher.
Here are a couple of examples of when webhook approach is used:
- SendGrid.com - an email service that let's you send emails and campaign emails through an api. One example when you would like to expose a webhook on your backend would be if you want to get notified every time a user unsubscribes from a list.
- Braintree.com - a billing gateway the lets you charge your customers for products they buy on your website - an example would be a webhook you expose on your backend in order to get a notification every time a recurring payment was successfully executed

When it comes to publisher/subscriber this is more of a messaging pattern (from Wikipedia) :

In software architecture, publish–subscribe is a messaging pattern where senders of messages, called publishers, do not program the messages to be sent directly to specific receivers, called 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.

Advantages
Loose coupling
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. Each can continue to operate normally regardless of the other. In the traditional tightly coupled client–server paradigm, the client cannot post messages to the server while the server process is not running, nor can the server receive messages unless the client is running. Many pub/sub systems decouple not only the locations of the publishers and subscribers, but also decouple them temporally. A common strategy used by middleware analysts with such pub/sub systems is to take down a publisher to allow the subscriber to work through the backlog (a form of bandwidth throttling).
Scalability
Provides the opportunity for better scalability than traditional client–server, through parallel operation, message caching, tree-based or network-based routing, etc. However, in certain types of tightly coupled, high-volume enterprise environments, as systems scale up to become data centers with thousands of servers sharing the pub/sub infrastructure, current vendor systems often lose this benefit; scalability for pub/sub products under high load in these contexts is a research challenge. Outside of the enterprise environment, on the other hand, the pub/sub paradigm has proven its scalability to volumes far beyond those of a single data centre, providing Internet-wide distributed messaging through web syndication protocols such as RSS and Atom. These syndication protocols accept higher latency and lack of delivery guarantees in exchange for the ability for even a low-end web server to syndicate messages to (potentially) millions of separate subscriber nodes.
Disadvantages
The most serious problems with pub/sub systems are a side-effect of their main advantage: the decoupling of publisher from subscriber.
I would recommend the following post for further info about pub/sub :

• pub-sub-messsaging using aws
• Pub sub on Wikipedia