loading...

Whats your take on Webhooks?

vkassingh profile image Vikas Singh ・1 min read

Here is mine:
WEBHOOKS Vikas Singh
Webhooks allows one web app to share real-time data to any other web app

Comment out more about webhooks

Discussion

pic
Editor guide
Collapse
arturssmirnovs profile image
Arturs Smirnovs

I personally don't trust web hook callbacks..
If they check that response was successful then sure..

But i have been always afraid that if webhook callback is sent and application triggers error and data is not synchronized.. what next?

I would better build it in on my application side to send request to third party application to get data.. not wait for callback from them..

Collapse
nostop8 profile image
Volodymyr Dovbenko

I do not trust anything, even my own code. The point of webhooks is to allow immediate notifications between different parties. That's a requirement of nowadays where everything should happened very fast, almost instantly. Sending some regular request to the 3rd party from your application should be as a fallback solution, to make sure that the data is in sync in case something went wrong with the webhooks. Though, in 99.9% of cases it all we be fine with webhooks.

Collapse
darkwiiplayer profile image
DarkWiiPlayer

Error handling depends very much on the implementation (on both sides). HTTP allows for very robust error-handling, and a web-hook can choose to try again or send a notification to an administrator when message delivery fails, and the callee can communicate what went wrong and whether the caller should try again.

Collapse
nieuwepixels profile image
Nieuwe Pixels

Nice insight. I think both should be available. There is a case to be made for both depending on the data/task.

Collapse
badpracticeio profile image
Bad Practice

Stripe is the perfect example for making sure your webhooks are secure and filled with contingencies (helping you test error handling).

Collapse
nostop8 profile image
Volodymyr Dovbenko

Nowadays I can't imagine integration with some 3rd parties without webhooks. For instance payment processing. After successful payment you cannot rely on the client in order to confirm the successful payment. Waiting for some regular cron job which can run even every minute to confirm the payment status on the server side is OK and should be in place as a fallback option, but it is way too slow. So webhooks is a "must" for communication between different parties in order to notify each other about any events.

Collapse
jsmrcaga profile image
Jo Colina

Webhooks are an amazing implementation.
As Arthurs says, they can fail (how many times have we seen Travis not triggered because the GitHub webhooks were out of order?), but they are extremely efficient.

Implementing on your own server is easy, and separating them into another service ensures performance on both sides.

On the receiving side, if your application is fault tolerant there should be no problem. A bad response should trigger a specific HTTP status code that will prompt the sender to stop and maybe notify their user (403 for example), and if you don't get an event, then there's nothing you can do, so no specific management there.

Every modern app should have some sort of webhook implmentation, whether receiving (GitHub, Zapier, Stripe...) or sender (Zapier, IFTTT, other business integrations).

Collapse
darkwiiplayer profile image
DarkWiiPlayer

They're just REST API calls, so yea, I guess they make sense. There's certainly situations where a more specialized tech like MQTT would be a better choice, but for many applications it's just more user-friendly to deliver your data via REST.

Collapse
joelbonetr profile image
JoelBonetR

That's a really brief explanation LoL