3 ms·

Webhooks are _not_ great. Unless you want to offload them to a platform like yours, they are entirely too complex and require way more engineering effort to get

Webhooks are _not_ great. Unless you want to offload them to a platform like yours, they are entirely too complex and require way more engineering effort to get right and be reliable. It's not enough to just issue a POST to the user-provided URL (I know I'm preaching to the choir on that). However, Webhooks are also generally not ideal for most users. Why spin up new infra to handle occasional messages over the public Internet? It's just a legacy approach that is on its way out. Wasm will replace them over time, as we can now run the event-driven user code in-process in the source application and shed the need to needlessly split up these systems, over-engineering distributed systems to just modify some data before it goes into a database or run a little function here and there.

cuu508 3y ago
Let's say I use some SaaS for handling payments and subscriptions. The SaaS can notify me via a webhook when a user successfully creates a subscription on their hosted payment page, so I can, let's say, adjust their allowed features and resource limits on my end. If we throw away webhooks, how would this work with Wasm?
- nilslice 3y ago
  The SaaS can run your wasm code for you. In this case, you'd write the same code that you'd otherwise run in your infra to respond to the webhook, but it would be compiled to Wasm and run _in the SaaS app_ where the source event was triggered. In your specific case, you'd still be making a call-out to your system to adjust the entitlements as you describe. However, many cases are actually taking action back on the SaaS side via API calls to the SaaS. So instead of a handful of back-and-forth calls over the Internet between you and SaaS, you just call their functions from the Wasm code running in their infra.
  - deleted 3y ago
    [deleted]
  - tonyhb 3y ago
    So you have to give your 3rd party providers access to _code you write_, _secrets to your own datastores_, _open firewalls to 3rd parties_, and then allow them to run any code which could access your system, hoping that they do in fact run the blob you upload?
    - nilslice 3y ago
      pretty much everything of any level of sophistication require this. unsure what your point is. wouldn't your customers for inngest need to do the same for anything integrated?
      - goodoldneon 3y ago
        No, Inngest doesn't host your code so it doesn't need your secrets
        nilslice 3y ago
        yet
  - jddj 3y ago
    I've re-read this a few times to try to grasp the wisdom which the confident contrarian tone makes me suspect is in there. I have to say I couldn't find it. Could you give an example scenario where the status quo would be improved by uploading a wasm handler to a server instead of passing messages?
    - nilslice 3y ago
      Look at the Shopify Functions platform
- nilslice 3y ago
  In fact, your platform (https://healthchecks.io/ https://healthchecks.io/) is a prime example of where running customer wasm would be really excellent. Instead of sending webhooks out to customer configured URLs, you could run a Wasm environment to execute customer code. Off hand, a good use case here is to do further inspection of the event before it gets sent off to some other system - maybe there are cases where you send false-positives and needlessly trigger external system alerts. The customer Wasm could do more introspection on the healthcheck event and make a more informed decision about how to proceed.
hn_throwaway_99 3y ago
> However, Webhooks are also generally not ideal for most users. Why spin up new infra to handle occasional messages over the public Internet? It's just a legacy approach that is on its way out. I'm trying to be generous here, but I don't see any evidence that webhooks "are just a legacy approach that is on its way out". Your next paragraph basically highlights what I mean: > Wasm will replace them over time, as we can now run the event-driven user code in-process in the source application and shed the need to needlessly split up these systems, over-engineering distributed systems to just modify some data before it goes into a database or run a little function here and there. This feels like a "not even wrong" statement to me. Yes, I think things like hosted plugins are a good thing, but that is only a very small slice of what webhooks are used for. A huge value of webhooks is that while I get the notifications from some external system I can, and I want to, run the handler in my own infrastructure. While this may be a burden for some teams, for many others it is most definitely a feature. I'm not sure if you're the author of this blog post, but I think it would have been much better if it just talked about how "hosted plugins" can be a good alternative to some of the things webhooks have been used for. But weirdly turning this idea into "webhooks suck" makes no sense.
- nilslice 3y ago
  I'm not the author -- but I do think webhooks generally are misused and need something new, not just a step-change improvement. For integration and extensibility, webhooks are definitely the wrong choice. For handling event notifications, fine, but I don't see the majority of webhooks used like this. And even if they are, there's inevitably a bunch of cross-talk over the Internet to handle the event, make a follow-on request to the SaaS API, handle its response, rinse and repeat. We can do better.
  - hn_throwaway_99 3y ago
    > but I don't see the majority of webhooks used like this. Can you give some examples of webhooks that are used solely for this "integration and extensibility" reason, because essentially all of my uses of webhooks have been to handle event notifications, but perhaps I'm just misunderstanding how you're making this distinction. For example, I work in fintech, and the main thing I use webhooks for is to get notified of a whole host of things that happen "in the real world" outside of my app (e.g. when a bank card is swiped, when an ACH is processed, when an account application is approved or denied, etc.) > And even if they are, there's inevitably a bunch of cross-talk over the Internet to handle the event, make a follow-on request to the SaaS API, handle its response, rinse and repeat I don't even understand why that would be considered a problem. So what, I make an API call to get some additional data so I can do something with it in my infrastructure? I mean, I'm going to need to write something to get the code to do what I want. There is literally 0 downside, from a business perspective, to "a bunch of cross-talk over the Internet" - why should I even worry about this? I just generally feel that perhaps this article and what you are referring to have something very specific in mind when you talk about webhooks and what they're used for. I'd just argue that there is a much broader set of use cases out there for webhooks, so I think a better approach is to lay down how you think this kind of "plugin architecture" would be an improvement and highlight some examples where you think webhooks would be a bad fit.

cuu508 3y ago

Let's say I use some SaaS for handling payments and subscriptions. The SaaS can notify me via a webhook when a user successfully creates a subscription on their hosted payment page, so I can, let's say, adjust their allowed features and resource limits on my end. If we throw away webhooks, how would this work with Wasm?

nilslice 3y ago
The SaaS can run your wasm code for you. In this case, you'd write the same code that you'd otherwise run in your infra to respond to the webhook, but it would be compiled to Wasm and run _in the SaaS app_ where the source event was triggered. In your specific case, you'd still be making a call-out to your system to adjust the entitlements as you describe. However, many cases are actually taking action back on the SaaS side via API calls to the SaaS. So instead of a handful of back-and-forth calls over the Internet between you and SaaS, you just call their functions from the Wasm code running in their infra.
- deleted 3y ago
  [deleted]
- tonyhb 3y ago
  So you have to give your 3rd party providers access to _code you write_, _secrets to your own datastores_, _open firewalls to 3rd parties_, and then allow them to run any code which could access your system, hoping that they do in fact run the blob you upload?
  - nilslice 3y ago
    pretty much everything of any level of sophistication require this. unsure what your point is. wouldn't your customers for inngest need to do the same for anything integrated?
    - goodoldneon 3y ago
      No, Inngest doesn't host your code so it doesn't need your secrets
      - nilslice 3y ago
        yet
- jddj 3y ago
  I've re-read this a few times to try to grasp the wisdom which the confident contrarian tone makes me suspect is in there. I have to say I couldn't find it. Could you give an example scenario where the status quo would be improved by uploading a wasm handler to a server instead of passing messages?
  - nilslice 3y ago
    Look at the Shopify Functions platform
nilslice 3y ago
In fact, your platform (https://healthchecks.io/ https://healthchecks.io/) is a prime example of where running customer wasm would be really excellent. Instead of sending webhooks out to customer configured URLs, you could run a Wasm environment to execute customer code. Off hand, a good use case here is to do further inspection of the event before it gets sent off to some other system - maybe there are cases where you send false-positives and needlessly trigger external system alerts. The customer Wasm could do more introspection on the healthcheck event and make a more informed decision about how to proceed.

hn_throwaway_99 3y ago

> However, Webhooks are also generally not ideal for most users. Why spin up new infra to handle occasional messages over the public Internet? It's just a legacy approach that is on its way out. I'm trying to be generous here, but I don't see any evidence that webhooks "are just a legacy approach that is on its way out". Your next paragraph basically highlights what I mean: > Wasm will replace them over time, as we can now run the event-driven user code in-process in the source application and shed the need to needlessly split up these systems, over-engineering distributed systems to just modify some data before it goes into a database or run a little function here and there. This feels like a "not even wrong" statement to me. Yes, I think things like hosted plugins are a good thing, but that is only a very small slice of what webhooks are used for. A huge value of webhooks is that while I get the notifications from some external system I can, and I want to, run the handler in my own infrastructure. While this may be a burden for some teams, for many others it is most definitely a feature. I'm not sure if you're the author of this blog post, but I think it would have been much better if it just talked about how "hosted plugins" can be a good alternative to some of the things webhooks have been used for. But weirdly turning this idea into "webhooks suck" makes no sense.

nilslice 3y ago
I'm not the author -- but I do think webhooks generally are misused and need something new, not just a step-change improvement. For integration and extensibility, webhooks are definitely the wrong choice. For handling event notifications, fine, but I don't see the majority of webhooks used like this. And even if they are, there's inevitably a bunch of cross-talk over the Internet to handle the event, make a follow-on request to the SaaS API, handle its response, rinse and repeat. We can do better.
- hn_throwaway_99 3y ago
  > but I don't see the majority of webhooks used like this. Can you give some examples of webhooks that are used solely for this "integration and extensibility" reason, because essentially all of my uses of webhooks have been to handle event notifications, but perhaps I'm just misunderstanding how you're making this distinction. For example, I work in fintech, and the main thing I use webhooks for is to get notified of a whole host of things that happen "in the real world" outside of my app (e.g. when a bank card is swiped, when an ACH is processed, when an account application is approved or denied, etc.) > And even if they are, there's inevitably a bunch of cross-talk over the Internet to handle the event, make a follow-on request to the SaaS API, handle its response, rinse and repeat I don't even understand why that would be considered a problem. So what, I make an API call to get some additional data so I can do something with it in my infrastructure? I mean, I'm going to need to write something to get the code to do what I want. There is literally 0 downside, from a business perspective, to "a bunch of cross-talk over the Internet" - why should I even worry about this? I just generally feel that perhaps this article and what you are referring to have something very specific in mind when you talk about webhooks and what they're used for. I'd just argue that there is a much broader set of use cases out there for webhooks, so I think a better approach is to lay down how you think this kind of "plugin architecture" would be an improvement and highlight some examples where you think webhooks would be a bad fit.