1–10 of 13 posts
Pains / concerns:
* Local development is annoying (ngrok, etc.)
* Security is low
* Doesn't work super well with serverless stack
Curious how others are thinking about this.
- An HTTP request is like a function call (a named function, with arguments as path/params/body)
- A webhook is like a callback (albeit across a network boundary)
- For security, services that invoke webhooks usually cryptographically sign their payloads to allow their authenticity to be verified.
- Maybe you mean something else by serverless, but in my experience, it has been relatively easy to deploy an AWS Lambda function (e.g. using Serverless Framework) that gets called by a webhook.
Webhooks aren't perfect, but they do seem significantly simpler than the alternatives that come to mind, like WebSockets or WebRTC. Long polling is simpler, but often that is already an option for services that provide webhooks. I'll be interested to see if others have ideas for better alternatives, though.
Some of my customers also use these:
https://zapier.com/page/webhooks/
https://support.discord.com/hc/en-us/articles/228383668-Intr...
This is an article on the subject I really enjoyed recently: https://blog.sequin.io/events-not-webhooks
As for webhooks, my impression was that the main advantage was for the sender, not the receiver, because they don't have to deal with thousands of long-lived connections anymore.
My suspicion is that the big names who introduced webhooks first were quite aware of the potential downsides for reveivers but found them acceptable. (See e.g. twitter switching from a websocket-like "firehose" to webhooks)
If that was the case, then neither websockets nor (long) polling will be a viable replacement for webhooks because senders won't adopt it.
This is an article on the subject I really enjoyed recently: https://blog.sequin.io/events-not-webhooks
Maybe it's a matter of perspective, but I don't understand why websockets are seen as super complex and error-prone, while long polling is supposed to be simple and elegant. Both are long-lived connections, where the client connects but the server pushes data. Where is the difference? As for webhooks, my impression was that the main advantage was for the sender , not the receiver, because they don't have to deal with…
But most people never need to implement an HTTP proxy. On the client side it's less of an issue, except it usually entails adding a dependency to your project unless you're using browser JavaScript.
For large services, I could see maintaining many open WebSockets becoming an issue, whereas with polling you can rate limit clients fairly easily to control the number of open connections you have.
I agree that local development is annoying, but I haven't found the other two to be pain points: - For security, services that invoke webhooks usually cryptographically sign their payloads to allow their authenticity to be verified. - Maybe you mean something else by serverless, but in my experience, it has been relatively easy to deploy an AWS Lambda function (e.g. using Serverless Framework) that gets called by a w…
Maybe it's a standards thing. Perhaps if there were a standard for webhook format / security and then a lib to easily create / ingest.