Standard Webhooks: open-source tools and guidelines for sending webhooks • Hacker News Board

Re: Standard Webhooks: open-source tools and guidelines for sending webhooks

#31

Post by strken » Fri, Dec 08, 2023, 2:25 PM UTC

stephenr wrote: post #29

strken wrote: post #26

Earlier quoted context omitted.

You could use SSE, long polling, or even a webhook. With the latter two you'd miss out on some of the performance gains of not needing to re-establish a connection unless the producer does http streaming, but the main stability points are not using webhooks as the sole means of delivery and not flushing events after they're delivered. So many webhook implementations don't go far enough and just fling events at the co…

I mean, you can use anything if you just want a dumb pipe to put an ad-hoc data stream over. My point is that SSE is already a standard to do exactly the thing you're asking for: publish a one-way event stream, with a built-in mechanism for reconnecting and telling the remote end the last event you received (so you can catch up on anything missed during the disconnected period).

Right, sure, I've never used it outside a browser but I guess it would work fine. My point is that A) no matter which standard you use for sending a stream of events it's probably better than a webhook, and B) it's still important to provide both a long retention window and good tools to query events for debugging no matter what you use.

Re: Standard Webhooks: open-source tools and guidelines for sending webhooks

#32

Post by tasn » Fri, Dec 08, 2023, 2:27 PM UTC

theogravity wrote: post #28

The signature format is just weird. Why not include it as part of the request headers? Edit: It seems to also have a header version. Not sure why there's two different ways to pass a signature here.

It's only passed as a header. Where did you see the other way of passing it? We'll clarify the spec if confusing.

Re: Standard Webhooks: open-source tools and guidelines for sending webhooks

#33

Post by nerdponx » Fri, Dec 08, 2023, 5:36 PM UTC

kisamoto wrote: post #27

I'm curious as to why webhooks are becoming a defacto standard for triggering events between isolated systems. Why not have a dedicated event bus (could be - but not limited to - kafka, NATS etc.) where remote systems connect to dedicated event queues? Push a message onto the queue which is picked up by the remote system. Authentication is handled by the event bus which can also act as a storage for message (re)deliv…

> dedicated event bus

A webhook is "peer-to-peer" and uses the existing HTTP infrastructure that's already in your application. Whereas an event bus is "centralized" and requires a third service to run/maintain/design. I'd like to avoid that if possible.

Also webhooks make a lot of sense for communication between organizations, which you can't do with a centralized event bus (unless someone is out there running a global event bus that I'm not aware of). Let's say I'm using Managed Service Foo hosted by a third party, and I want to trigger some event in my own system whenever certain things happen in side Managed Service Foo. How else do you expect me to receive those events? Surely a webhook is a lot easier than figuring out an event bus to be shared across our two organizations.