2 ms·
Having built a webhook system for our product, I'd caveat that webhooks are "harder than they seem, but not that hard". The big components we ran into were: 1
by themanmaran 2y ago
Having built a webhook system for our product, I'd caveat that webhooks are "harder than they seem, but not that hard".
The big components we ran into were:
1. Having retry logic if you don't get a 200 back. And some way of flagging the failed requests. We already had a pretty robust job queue/worker setup on our side, so it was a lot easier to add webhooks with that logic in place.
2. Keeping a webhook log. On our side we had a request history already that kept a log of our LLM requests, so it was pretty easy to reuse.
3. Auth / dev experience. Some way for a developer to put in a url + headers + auth method and click "test".
- marcosdumay 2y agoWeb-hooks create distributed systems. So they are "distributed systems" hard. What means that, if you know your timing, miltiplicity, and reliability requirements and guarantees, you can solve most problems by taking the best design pieces from the state of the art (idempotency, write-only logic, retrials, optimist atomicity, peer election...) and applying whatever you can to simplify your code as most as possible. If you know how, you can probably solve most problems just fine. But you must know how, and you must know the problem.
- djbusby 2y agoWe had this problem at work too. And didn't want yet another service provider. Built our own, in Go, for incoming and outgoing. Has some routing features too. Client Webhooks configs stored in that service and our main app API to that thing to configure. Not optimized for scale, likely only a few thousand per second capable.
- yjftsjthsd-h 2y ago> 1. Having retry logic if you don't get a 200 back. And some way of flagging the failed requests. With exponential/random backoff?