Webhooks do’s and dont’s: what we learned after integrating APIs • Hacker News Board

Re: Webhooks do’s and dont’s: what we learned after integrating APIs

#81

Post by jon-wood » Wed, Nov 23, 2016, 2:22 PM UTC

fiatjaf wrote: post #56

jon-wood wrote: post #17

Earlier quoted context omitted.

It's not AMQP (sadly) but something I've done previously is to have the actual webhook endpoint be as dumb as possible, doing nothing but accepting the payload (maybe with some very high level validation that the request was expected) and pushing it into a real queueing system. This means you can handle all sorts of failure modes, not just the backend going down, but also bugs in the consumer that would otherwise res…

Shameless plug: https://requesthub.xyz is ideal for these cases.

That's pretty awesome, thanks for the tip.

Re: Webhooks do’s and dont’s: what we learned after integrating APIs

#82

Post by jeffnappi » Wed, Nov 23, 2016, 6:05 PM UTC

intellent wrote: post #80

What I am most interested in is how to test/debug webhooks during development. How do I tell webhook providers to send test notifications to my local development instance without tampering with the production setup on both sides?

This is another thing that Stripe nails. Out of the box it comes with a Test mode and you can easily use this to test your webhook implementation.

Another way to handle this is to create and maintain a mocking tool that will generate requests.

Re: Webhooks do’s and dont’s: what we learned after integrating APIs

#83

Post by akamaozu » Thu, Nov 24, 2016, 3:42 AM UTC

blairanderson wrote: post #69

bazizbaziz wrote: post #16

How do people in production handle the possibility that your service might miss a webhook notification? If you miss a notification you'll end up with stale data and you won't know it. Slack has a retry policy for a while but will then just give up. Another webhook provider I've looked at says nothing at all about this sort of thing. How do folks deal with this in production systems? Seems to me like the best way to a…

I have recently moved all received webhooks to a job queue and have been very happy. you can retry the processing on your own terms.

This.

Previous devs were doing expensive things whenever we received webhooks. This meant we DoS'd ourselves every time a sizable amount of webhooks came our way.

Set up a tiny server on Heroku that received the webhooks and put them on a queue. A worker with a configurable concurrency level later forwards the events on the queue .

Dropped from four digit 502s and 504s weekly to virtually none.