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.<p>Furthermore, in the "Workflow builder" and "In-browser IDE", all the author is highlighting is the case where the <i>service provider</i> 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 <i>in their own infrastructure</i>. 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.
Obviously Deno have vested interest here (and so do I as the founder of Svix[1] which is mentioned in the post), but my take is that webhooks are great, though there are alternatives that could be better or complementary depending on the situation.<p>They bring up a few good points about the shortcomings of webhooks, many of these we are trying to improve for the whole ecosystem (e.g. with Standard Webhooks[2]), or solve in Svix directly including running JS instead of sending webhooks which we already support (using Deno, which is great!). It is very useful, but there are many limitations with this approach, and in general oftentimes people just want the data passed to their systems and deal with it there. Not write a bit of JS in the browser to do something ad-hoc. So running JS is nice, but it's not a silver bullet. This is also why we don't support WASM, because in most cases it's just not that useful.<p>So in short, like always with software engineering: "it depends" and there are tradeoffs to each approach.<p>1: <a href="https://www.svix.com">https://www.svix.com</a><p>2: <a href="https://www.standardwebhooks.com/" rel="nofollow">https://www.standardwebhooks.com/</a>
To me what stands out a lot in this article is the following:<p>> . However, with this more robust setup, you would need 4 new services (SQS, S3, a Publisher(s), and a Consumer(s)), just to handle a single webhook safely. This is a lot of new infrastructure, architecture, time, and effort.<p>I most certainly agree that it is a lot of work, but the issue feels in large self-inflicted because of the use of serverless. If you're using a monolithic setup with erlang or running any kind of queue on the side you are fine. You might need to setup some retry logic and alerts but that is done once.<p>Also the solution of providing a in-browser IDE sounds terrible, developers wouldn't have access to source control, their own tools nor any kind of ability for local testing. Using zapier or any third-party tool is IMO not worth it if its a serious project.
You do not want to host someone else's code. Webhooks are great because they simply require an endpoint.<p>If you host someone else's code, you also need to host their 3rd-party API keys, etc. You'll also have to combat spammers using your IPs to do bad stuff.
Webhooks' only dependencies are all common standards. They are platform agnostic and have a low barrier to entry. The reliability challenges are going to similar to any other self-hosted or self-managed infrastructure.<p>I get that you might want something better to shuttle a lot of data around between two apps but webhooks are relatively painless for a lot of straightforward interactions.
> deploy and host the server somewhere where it’s always available<p>This is such an underappreciated aspect; a naive webhook consumer service will just completely miss events in any outage. It means that if the information contained is important, you need a fallback approach to gathering it, usually by periodically polling the source system. And, it turns out that a lot of times that polling mechanism is good enough on its own; engineering to get the instant push, but only most of the time is of questionable business value.<p>Incidentally I think that consuming webhooks and converting them to messages on a queue are one of the true killer AWS Lambda and Lambda-like use-cases. Very spiky traffic, shouldn't matter if it's warm, availability is paramount. And if you stay disciplined about it--just routing the message to the queue, nothing else--you sidestep many of the function-as-a-service developer lifecycle frustrations.
Most complains in this article about webhooks sound like they can easily be resolved with some lambda function and a cloudfront (or any alternative to AWS) without much complication.
Am I seeing something wrong or not?