3 ms·

This article is premised on the incorrect strawman that webhooks are complicated because the consumer has an extra persisted message bus. But if the producer r

This article is premised on the incorrect strawman that webhooks are complicated because the consumer has an extra persisted message bus. But if the producer retries and the consumer does not respond with 200 until it has processed the message, no consumer side message queue is needed, the consumer can rely on the producer to reach at-least-once delivery. In both cases (webhooks and /events) storage is needed producer side, so nothing consequential has changed, only with /events you need long lived TCP connections which ties up (e.g. you can't do this on FaaS endpoints) Functions as a service are absolutely ideal for low frequency webhook receivers. SO SO SO cheap.

coder543 5y ago
> But if the producer retries and the consumer does not respond with 200 until it has processed the message, no consumer side message queue is needed, the consumer can rely on the producer to reach at-least-once delivery. Part of the point of the article was that you may deploy bad code which returns 200, but doesn't actually take the correct action with the events, and then you have lost all that data and have no way to get it back, which is why you have a consumer-side message bus to hold the webhook history, so that you can replay the webhooks if you made a mistake. Your comment does not address this at all. If the service exposes a /events page, and especially one that supports long polling (or SSE), then you no longer need a consumer-side message bus, and you might not even need webhooks at all. I definitely think webhooks should be offered, but I agree with the article that webhooks shouldn't be the only thing.
villasv 5y ago
The article specifically exemplifies the case of the web hook having faulty code (introducing nulls) while still not failing with errors. In this case if you don’t have storage on the consumer side, you have to ask for the producers to be merciful gods.
- ezekg 5y ago
  In this case, you can simply replay the badly handled webhooks. No need for long-polling.
  - villasv 5y ago
    Under the assumption of no storage on the consumption side given by parent commenter, there's no way to replay. Anyway, I was not making the case for long-polling.
alexbouchard 5y ago
I partially agree but the issue with relying on the producer delivery is that you effectively give up control on what the retry logic is. If it doesn't fit your use case, too bad for you. While ideally every platform would provide those configuration I think it's unreasonable to think all platforms will offer excellent webhook tools & configuration. You better just take things under your own hands.

coder543 5y ago

> But if the producer retries and the consumer does not respond with 200 until it has processed the message, no consumer side message queue is needed, the consumer can rely on the producer to reach at-least-once delivery. Part of the point of the article was that you may deploy bad code which returns 200, but doesn't actually take the correct action with the events, and then you have lost all that data and have no way to get it back, which is why you have a consumer-side message bus to hold the webhook history, so that you can replay the webhooks if you made a mistake. Your comment does not address this at all. If the service exposes a /events page, and especially one that supports long polling (or SSE), then you no longer need a consumer-side message bus, and you might not even need webhooks at all. I definitely think webhooks should be offered, but I agree with the article that webhooks shouldn't be the only thing.

villasv 5y ago

The article specifically exemplifies the case of the web hook having faulty code (introducing nulls) while still not failing with errors. In this case if you don’t have storage on the consumer side, you have to ask for the producers to be merciful gods.

ezekg 5y ago
In this case, you can simply replay the badly handled webhooks. No need for long-polling.
- villasv 5y ago
  Under the assumption of no storage on the consumption side given by parent commenter, there's no way to replay. Anyway, I was not making the case for long-polling.

alexbouchard 5y ago

I partially agree but the issue with relying on the producer delivery is that you effectively give up control on what the retry logic is. If it doesn't fit your use case, too bad for you. While ideally every platform would provide those configuration I think it's unreasonable to think all platforms will offer excellent webhook tools & configuration. You better just take things under your own hands.