DEV Community

Cover image for WebHook - An Introduction
Johnson Ogwuru
Johnson Ogwuru

Posted on • Updated on

WebHook - An Introduction

Most folks hate being micro-managed, we mostly want to be allowed to do our best work and not to be constantly reminded of it, or being repeatedly asked if we are done when it's obvious we aren't. This kind of behavior from direct managers and colleagues have forced some Engineers to tip their hat and resign from their positions.

But how would you feel to learn that your server-side application living and chilling on AWS or Azure feels exactly the same way when you repeatedly send a request to it, asking for data, which obviously isn't ready or doesn't exist?
I'm sure we won't want our server-side application to tip the hat and resign from its position when it can't take the repeated calls and request from us and the client-side. Little wonder, products like GitHub enforced a limit on the amount of request you could make to their server, just to be safe and sure that their server-side application stays happy and doesn't quit on them 🎩, from the possible billions of request that would come from uncontrolled access to it.

Now, the question on everyone's mind would be, if we are going to do away with having to repeatedly ask the server if it has something new for us, how would we be aware of changes on our server? Or are we expecting our users to be refreshing their browsers every 10minutes to get new content?

If we are running products that require reading lots of data like Twitter and GitHub, we definitely wouldn't expect our users to refresh their browsers every time they want to receive the latest information or feed in the case of Twitter, at least not in this our era of SPA's and Ajax.
So how do we tackle this problem?


drum roll

Introducing the Big Man...WebHooks 🥁🥁🎉🎉🎊🎊

The introduction of WebHooks led to a new form of communication between the client-side application and the server-side application.
Before now, the form of communication that exists between the client-side and the server-side is the one which had the client consuming the server, when making a request for a resource from the server.

consuming the backend by client

With a WebHook, the server-side this time consumes a resource from the client-side and not the other way around(the resource being the end-point URL provided by the client-side application), which is why the WebHook is commonly referred to as the "Reverse API".

The concept of a WebHook is simple. A WebHook is an HTTP callback or HTTP POST, that occurs when something happens; a simple event-notification via HTTP POST.
With WebHooks, we avoid the need for constant polling of the server-side application by the client-side application in search of certain resources, but rather the client-side is alerted whenever there is a change to such resources which it's interested in.

Thus, rather than the client-side application constantly polling the server-side application to check for new events, the server-side application calls the client-side application (by invoking a client provided webhook URL) anytime the server-side has something new to report to the client.

A WebHook has the ability of not just notifying the client-side of a change in the server-side, but can also take a payload, a payload which could be information about the new resource, but while it is possible to pass payload data within the body of the webhook, to improve scalability and reliability it is a good practice to keep the webhooks light-weight. Webhooks although technically can carry a payload, are only a callback mechanism, and primarily should serve as a signal for change in state.

Once the notification in the change of state is received, a separate API call could be made to the server requesting for the new resource. This separation of concern allows for improved scalability and reliability of the API integration. And this is exactly what Twitter and LinkedIn does when they allow you to update your timeline but only show you a button to do so when there is a new resource(tweet or post)

Thus, a webhook is nothing but a simple client-side provided end-point URL. This end-point URL has to be passed by the client-side application to the server-side application at some point prior to the webhook call by the server-side.

Resources:

  1. The following site allows you to test the concept of webhooks https://webhook.site/. It generates a unique test webhook URL that can be called by your application to test the callback (notification) feature of the webhook. You could further test it, by adding the link generated as a webHook in a GitHub repo's webhook setting and making a push to that repo and see the awesomeness of webhooks from webhook.site

  2. With regards to the argument about whether a webhook should have a payload, have a look at this article on medium by jsneddles

  3. For further read, check out https://codeburst.io/whats-a-webhook-1827b07a3ffa

Conclusion:
As this is a concept I just got to understand, it is possible, I didn't touch all aspects of it, and would love to get your kind feedbacks, questions, and contributions. Thanks.

Top comments (10)

Collapse
 
erebos-manannan profile image
Erebos Manannán

Just to clarify a few things: You don't use WebHooks for "client side" events, i.e. browsers.

They are meant for server to server notifications, when your backend wants to be notified of payments from PayPal, or other such things.

For client notifications people typically use something like a WebSocket combined with a Pub/Sub (Publisher-Subscriber) system that can handle the distribution of events efficiently in near-realtime to connected clients.

Collapse
 
eimihar profile image
Rahimie Ahmad

Agreed. I think the article got it wrong when it starts to use long polling as comparison. As both websocket and webhook are totally different concepts.

Other than that, it's a good article about webhook (client-side part aside)

Collapse
 
ogwurujohnson profile image
Johnson Ogwuru

Thanks Rahimie

Collapse
 
ogwurujohnson profile image
Johnson Ogwuru

awesome, thanks for this feedback

Collapse
 
stewartjarod profile image
Jarod Stewart

I think you may want to revise your article based on this feedback. Or at minimum remove the use-cases that you've mentioned that are incorrect.

I have maintained, created, and consumed many webhooks and I can concur, you would not use them for web apps for notifications, new tweets/posts, etc.

For more information on a webhook, I like to point to an old post my friends at SendGrid wrote: sendgrid.com/blog/whats-webhook/

Best of luck and continued learning!

Collapse
 
hemantparashar profile image
Hemant Parashar

Webhooks aren't meant for client side and definitely cannot notify the client of an event using HTTP POST. There needs to be a request from a client in order to receive a response from an endpoint of any sorts. Untill and unless you're using websockets, you'll still need to poll an endpoint to get a response/status.

Collapse
 
jeddevs profile image
Theo

An interesting read, certainly extended by understanding of webhooks, Thank you.

Collapse
 
ogwurujohnson profile image
Johnson Ogwuru

glad you enjoyed it Theo

Collapse
 
subu profile image
Subramanya Shenoy

Just a quick question is it a alternative for service worker + periodic sync ?

Collapse
 
urielsouza29 profile image
Uriel dos Santos Souza

SSE server sent events server to clients
Webhook server to server!