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

The Valley of Webhooks

weli.dev

Post reply on HN
Print view View original

61–70 of 108 posts

Re: The Valley of Webhooks

#61

Post by seandoe »

weli wrote: post #16
zrail wrote: post #4

Webhooks are a painful problem. To clarify, Stripe's events API definitely ships a cursor and polling it has been the method preferred by large consumers for a long time.

Stripe events API is one of the examples of how to do things properly. And SCROLL is just trying to create a common spec so that everyone offers a stripe-like event polling api.

Yea I had the same thought: "It sounds like the Stripe events API would fulfill his needs." But then you said

> Nobody serves this today. That’s the catch, and it’s also the point.

and I was left wondering what was missing.

Re: The Valley of Webhooks

#62

Post by anamexis »

bobbiechen wrote: post #36
toomim wrote: post #32

This is a nice writeup of the problems in using Webhooks for State Synchronization. I also noticed that the proposed solution is a pseudo IETF-style draft protocol called SCROLL... that happens to be remarkably similar to an actual IETF draft I am bringing to IETF 127 this November called "Braid-HTTP Subscriptions." Both drafts request a subscription with a GET plus a header: Scroll Request: GET /scroll/feed/customer…

Is it accurate to say this is something like long polling except you continue to hold the connection open for subsequent updates? Does this mean a server potentially needs to hold open a very large number of connections (one per client) even if there are no updates? And why formalize on HTTP rather than on a similar protocol over websockets?

And isn't that just Server-Sent Events (SSE)?

Re: The Valley of Webhooks

#63

Post by AgentME »

tlonny wrote: post #53

I much prefer cursor paginated API requests vs. webhooks. The obvious downside being that in order to not get 429'd you need a respectable poll frequency - meaning you lose reactivity to new events. Thus I think webhooks still have a place - but as a simple "poke" that can be sent to the client to tell them something has changed - supplementing a default low frequency polling interval. This gives us the best of both…

The Gmail API works nicely like this. There's a history.list endpoint where you can see the recent history of message additions and removals, you can query for just the history that's taken place since a specific event's historyId, and you can subscribe to push notifications (that can be delivered by webhook) which just tell you when there are new history events, and you're expected to hit the history.list endpoint to see what's new. Some dropped push notifications aren't a big deal.

Re: The Valley of Webhooks

#64

Post by tasn »

zbentley wrote: post #54
tasn wrote: post #45

Earlier quoted context omitted.

We (Svix, webhooks infra) actually help our customers directly write to Kafka topics, S3 buckets, SQS, etc. and have for a few years now. There are definitely people that adopt that, but receivers as well prefer the simplicity of webhooks.

> receivers as well prefer the simplicity of webhooks. Do you see receive-side customers as prepared to outright reject paying for vendors that only offer non-webhook event streams if there's a webhook-ful competitor available? Or is that preference more of the "well, it's easier to add a webhook route to our existing webapp than it is to run a stream consumer/cron/whatever, but neither of those two is cost- or effor…

I know (from our customers) that some of their customers make buying decisions based on the availability of webhooks. I'm unaware of anyone doing it based on the availability of our other functionality (but it could be I just don't have the data).

Though the data I do have: how many people adopt these advanced endpoints in practice (as we offer these), and it's less than webhooks.

Re: The Valley of Webhooks

#65

Post by stymaar »

The text ought to have been interesting, as the insight is real, but for god sake how can someone decently read the slop their LLM outputted as reply to their prompt “write a blog post about X” and just copy-paste as it is?!

Re: The Valley of Webhooks

#66

Post by stymaar »

cobbzilla wrote: post #8

The proposed “feed” solution is functionally indistinguishable from incremental reconciliation. The article presents a good framing and is well-written, but doesn’t really propose anything new.

> and is well-written

Nah, it's almost pure slop with just the em-dashes edited away.

Re: The Valley of Webhooks

#67

Post by dzonga »

toomim wrote: post #32

This is a nice writeup of the problems in using Webhooks for State Synchronization. I also noticed that the proposed solution is a pseudo IETF-style draft protocol called SCROLL... that happens to be remarkably similar to an actual IETF draft I am bringing to IETF 127 this November called "Braid-HTTP Subscriptions." Both drafts request a subscription with a GET plus a header: Scroll Request: GET /scroll/feed/customer…

the solution is good but what tends to happen is webhook providers are not gonna work on such a solution - why - because it puts 'work' on them.

hell this is without the proposal for a new protocol - just a 'GET' stream or paginated one like the author said.

whereas with web hooks - a consumer has to do all the work - as the article above outlined.

Re: The Valley of Webhooks

#69

Post by evolve-maz »

tlonny wrote: post #53

I much prefer cursor paginated API requests vs. webhooks. The obvious downside being that in order to not get 429'd you need a respectable poll frequency - meaning you lose reactivity to new events. Thus I think webhooks still have a place - but as a simple "poke" that can be sent to the client to tell them something has changed - supplementing a default low frequency polling interval. This gives us the best of both…

Yep, the poke pattern is additionally nice because it means my state reconciliation function is the same when running on cron interval vs event driven.

On the flip side, it helps to have endpoints which have a query param linking to some sort of resource update time stamp. That way you can query to only get those items changed since last poll.

Post reply on HN