The Valley of Webhooks

10 points | by weli an hour ago

4 comments

  • zffr 4 minutes ago

    With webhooks, consumers get to asynchronously respond to updates from a provider. If no data has changed, a provider will not send any updates.

    With SCROLL, consumers are responsible for choosing when to ask a provider for updates. Without a mechanism for knowing when data has changed, consumers will be forced to be pessimistic and poll providers for new data on some cadence.

    I see two issues with the proposal: (1) SCROLL will lead to an increase in unnecessary network traffic for both the consumer and provider, and (2) because a consumer cannot know when data has changed, the lag between a consumer's local model and the provider's data model will be larger when with Webhooks.

  • zrail 5 minutes ago

    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.

  • Terr_ 7 minutes ago

    The final conclusion here reminds me of "The Log: Real-time data's unifying abstraction" [0], which has unfortunately had a bit of link-rot since 2013.

    [0] https://news.ycombinator.com/item?id=6916557

  • hungryhobbit 8 minutes ago

    Dude is not wrong ... but good luck convincing the Internet to switch to a sane system, when everyone already thinks web hooks are a "solved problem".