Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

21–30 of 33 posts

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

#21

Post by strken »

TheCycoONE wrote: post #20
strken wrote: post #19

Earlier quoted context omitted.

I'm not totally anti-webhook or the person you replied to, but I'd prefer at-most-once delivery via something that establishes a reusable connection (grpc or even websockets?) and backed by an events endpoint like Stripe's where the client can read everything that would have been sent. That way the client can replay all the events at leisure and retries aren't the server's responsibility.

I also prefer events over a persistent connection for efficiency, but webhooks are far better when the client is using a function as a service model.

My experience is that if your server doesn't retry webhooks then you could be doing something more efficient, and if it does retry webhooks then that indicates it's important not to miss anything and you should use persistent events rather than relying on bug-prone "if there's a 200, drop the event from the DB" webhook retries from the server.

I do think there's an argument for the interoperability of webhooks for integrating different services. I'm skeptical that they're the best choice from a purely technical perspective.

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

#22

Post by stephenr »

strken wrote: post #19
paulddraper wrote: post #13

Earlier quoted context omitted.

what is your suggestion for duplex communication?

I'm not totally anti-webhook or the person you replied to, but I'd prefer at-most-once delivery via something that establishes a reusable connection (grpc or even websockets?) and backed by an events endpoint like Stripe's where the client can read everything that would have been sent. That way the client can replay all the events at leisure and retries aren't the server's responsibility.

> I'd prefer at-most-once delivery via something that establishes a reusable connection (grpc or even websockets?) and backed by an events endpoint like Stripe's where the client can read everything that would have been sent. That way the client can replay all the events at leisure and retries aren't the server's responsibility.

Isn't that basically a description of SSE (https://en.m.wikipedia.org/wiki/Server-sent_events)?

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

#23

Post by js2 »

rkeene2 wrote: post #18
rkeene2 wrote: post #17

Earlier quoted context omitted.

The only advantage is that it validates that the send composed the message in the case without a shared secret (which is not what the article appears to advocate for). A shared secret alone, or an HMAC based on a shared secret, just means any party with the secret -- which could include anyone who would need to verify it -- composed the message. I generally don't do what's advocated for in the article because it does…

Although this ONLY holds if you're using HTTPS -- which is a separate thing, so maybe they're considering that you might not use HTTPS.

In my case I'm using mTLS and verifying the CN of the client cert. This is for an internal service. I'm also surprised the recommended headers doesn't include the event type. I found it beneficial to be able route the event before parsing the body and w/o having to use different endpoints.

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

#24

Post by tonyhb »

AustinBGibbons wrote: post #15

Good sign to me is one of the steering members is Tom Hacohen founder of Svix (webhooks-as-a-service). We're adopting them where I work and everything from them has been solid. I know he's seen a lot of different use cases and will have good consideration for the schema they define in their spec file.

Hard agree, they're a great team who have more knowledge in this space than almost anyone. The spec is great and makes a ton of sense.

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

#25

Post by simonw »

TheCycoONE wrote: post #20
strken wrote: post #19

Earlier quoted context omitted.

I'm not totally anti-webhook or the person you replied to, but I'd prefer at-most-once delivery via something that establishes a reusable connection (grpc or even websockets?) and backed by an events endpoint like Stripe's where the client can read everything that would have been sent. That way the client can replay all the events at leisure and retries aren't the server's responsibility.

I also prefer events over a persistent connection for efficiency, but webhooks are far better when the client is using a function as a service model.

Right: in this day and age there are an almost unlimited array of inexpensive, easy ways to spin up an HTTP endpoint that can receive a POST request.

We have a lot of experience scaling those kinds of endpoints (and making them redundant) too.

Spinning up an always-on server that can maintain a persistent connection - and reconnect automatically if it drops, and if the server is rebooted with an update and suchlike - is a whole lot harder. Possible, but not nearly as easy.

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

#26

Post by strken »

stephenr wrote: post #22
strken wrote: post #19

Earlier quoted context omitted.

I'm not totally anti-webhook or the person you replied to, but I'd prefer at-most-once delivery via something that establishes a reusable connection (grpc or even websockets?) and backed by an events endpoint like Stripe's where the client can read everything that would have been sent. That way the client can replay all the events at leisure and retries aren't the server's responsibility.

> I'd prefer at-most-once delivery via something that establishes a reusable connection (grpc or even websockets?) and backed by an events endpoint like Stripe's where the client can read everything that would have been sent. That way the client can replay all the events at leisure and retries aren't the server's responsibility. Isn't that basically a description of SSE ( https://en.m.wikipedia.org/wiki/Server-sent_e…

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 consumer with a short-term retry policy, or none at all, and then don't provide a way to see what events got missed.

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

#27

Post by kisamoto »

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)delivery. Partitioned by customer ID for separation of concerns etc.

Anything immediately obvious why this wouldn't be a preferred option or is it because HTTP is just easier to implement across systems?

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

#29

Post by stephenr »

strken wrote: post #26
stephenr wrote: post #22

Earlier quoted context omitted.

> I'd prefer at-most-once delivery via something that establishes a reusable connection (grpc or even websockets?) and backed by an events endpoint like Stripe's where the client can read everything that would have been sent. That way the client can replay all the events at leisure and retries aren't the server's responsibility. Isn't that basically a description of SSE ( https://en.m.wikipedia.org/wiki/Server-sent_e…

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).

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

#30

Post by dwb »

paulddraper wrote: post #12
dwb wrote: post #3

I wondered, "whose standard?", and was pleasantly surprised to find a list of real names [1] on the website. Nonetheless, I do bristle at the semantic weight of the name despite the fact it's not attached to a relevant existing institution. [1]: https://www.standardwebhooks.com/#committee

idk man, no one bristles at the S&P 500.

? That's obviously just a name, it's not making a claim.
Post reply on HN