3 ms·

This article made zilcho sense to me. I kept waiting for the part where it was going to tell me what was wrong with webhooks, but when it actually did it felt l

This article made zilcho sense to me. I kept waiting for the part where it was going to tell me what was wrong with webhooks, but when it actually did it felt like one of those "where did the soda go" things, with overly-complicated emphasis on things that aren't really problems. "The hidden cost of webhooks" section is basically just complaining that you need to run your own actual server, including "maintain the code". Even that is really overkill because it's easy to set up any number of lambdas/cloud functions/workers to respond to webhooks. Furthermore, in the "Workflow builder" and "In-browser IDE", all the author is highlighting is the case where the service provider is hosting the handler code, as opposed to the customer. But a whole, major point of webhooks is that they allow clients to run code in reaction to their SaaS APIs' events, but in their own infrastructure. I mean certainly, of course, if the provider wants to take the cost and risk of running their clients' code, that's a great service to provide, but I wouldn't say that highlights the negatives of webhooks.

codeonline 3y ago
Yes, I felt the same, I thought I was unaware of some fundamental flaw of webhooks. I feel webooks have lasted because they are the simplest thing that gets the job done. They only rely upon open standards like http, they are secured via tls, have well understood failure scenarios.
spiderice 3y ago
Agreed. This was one of the most underwhelming conclusions to an article I've seen in a while. Given the domain name of the blog, I thought Deno was offering some sort of next-generation webhook alternative that would actually be good. Instead, the "solutions" to webhooks (which are great, btw) are... workflow builders and in app IDEs? What the hell?
- crabmusket 3y ago
  They kind of buried the lede: the alternative is their "subhosting". This is similar to Cloudflare's "workers for platforms", or some of Fermyon's former marketing. The idea is that your SaaS would offer an interface for your customers' developers to build integrations directly in your own product. I guess like building Zapier into your product.
  - hn_throwaway_99 3y ago
    Thank you for this, I certainly misunderstood it. But this just means my comment was correct: they're basically just highlighting that the downsides of webhooks are that the customer needs to run their own infrastructure, but here they are (essentially) arguing that it's better to build a plugin system on their platform. And that may all make sense! But framing it as "Webhooks suck" is such a bizarre choice to me, primarily because they have an extremely limited view of what webhooks are used for in the first place.

codeonline 3y ago

Yes, I felt the same, I thought I was unaware of some fundamental flaw of webhooks. I feel webooks have lasted because they are the simplest thing that gets the job done. They only rely upon open standards like http, they are secured via tls, have well understood failure scenarios.

spiderice 3y ago

Agreed. This was one of the most underwhelming conclusions to an article I've seen in a while. Given the domain name of the blog, I thought Deno was offering some sort of next-generation webhook alternative that would actually be good. Instead, the "solutions" to webhooks (which are great, btw) are... workflow builders and in app IDEs? What the hell?

crabmusket 3y ago
They kind of buried the lede: the alternative is their "subhosting". This is similar to Cloudflare's "workers for platforms", or some of Fermyon's former marketing. The idea is that your SaaS would offer an interface for your customers' developers to build integrations directly in your own product. I guess like building Zapier into your product.
- hn_throwaway_99 3y ago
  Thank you for this, I certainly misunderstood it. But this just means my comment was correct: they're basically just highlighting that the downsides of webhooks are that the customer needs to run their own infrastructure, but here they are (essentially) arguing that it's better to build a plugin system on their platform. And that may all make sense! But framing it as "Webhooks suck" is such a bizarre choice to me, primarily because they have an extremely limited view of what webhooks are used for in the first place.