Ask HN: What Comes After Webhooks?
I feel like it's time for an improvement on / replacement for webhooks.
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. 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 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. My main issue with WebSockets in terms of complexity comes on the server side, specifically with Upgrade being a hop-by-hop header, it's a bit of a pain to implement as a proxy, and I still haven't implemented WS support in boringproxy for this reason. Whereas polling using the same plumbing as everything else. Even server sent events are essentially just HTTP, though they're crippled with HTTP/1.1 and limited to text data. 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 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. I have seen cryptography on some webhooks, but after doing about 30+ integrations at my old company, most were very basic / no auth. Maybe it's a standards thing. Perhaps if there were a standard for webhook format / security and then a lib to easily create / ingest. No answers, but since you asked about ways to think about the problem, here's one interpretation: - 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) I guess "Webhooks as a service" would come next and alleviate some of these issues. As discussed here:
https://news.ycombinator.com/item?id=27528202 Some of my customers also use these: https://zapier.com/page/webhooks/ https://support.discord.com/hc/en-us/articles/228383668-Intr... Thanks for these links. Really helpful. Curious if you're seeing technology businesses leverage Zapier? For some reason I've always assumed that's for places without a real dev team. Places like MailGun that don't support any type of authentication. Stripe and GitHub do it well. We're working on a solution to solve a lot of this, especially for event data. We push events directly to your customers, so they neither need to pull them or build webhook endpoints. Contact me if your interested. This would be what AWS’ Event Bridge and Event Bus are trying to solve. Pitty it is not a standard across multiple cloud providers.