logoalt Hacker News

zffrtoday at 4:16 PM2 repliesview on HN

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.


Replies

lxgrtoday at 4:33 PM

Assuming you're not using the proposed streaming option, I suppose you could always send a webhook for that fact alone? In other words, an empty notification, with semantics of "something has probably changed, better poll the SCROLL if you aren't already".

show 1 reply
inigyoutoday at 4:35 PM

If your API is just wrapping Kafka, it can long-poll