What happens if you need to catch up? You keep calling in a loop with a new lastEventId?
What is the intention there though. Is this for social media type feeds, or is this meant for synchronising data (at the extreme for DB replication for example!).
What if anything is expected of the producer in terms of how long to store events?
Use HTTP server-sent events instead. Those can keep the connection open so you don't have to poll to get real-time updates and they will also let you resume from the last entry you saw previously.
Yeah, but in real life, SSE error events are not robust, so you still have to do manual heartbeat messages and tear down and reestablish the connection when the user changes networks, etc. In the end, long-polling with batched events is not actually all that different from SSE with ping/pong heartbeats, and with long-polling, you get the benefit of normal load balancing and other standard HTTP things
Never heard of "CloudEvents" before. How do people feel about those?
It could use a section on high level justification / inspiration.
For example, what inspired this over a typical paginated API that lets you sort old to new with an afterId parameter?
Previously discussed (April 2022; 95 comments): https://news.ycombinator.com/item?id=30904220
What happens if you need to catch up? You keep calling in a loop with a new lastEventId?
What is the intention there though. Is this for social media type feeds, or is this meant for synchronising data (at the extreme for DB replication for example!).
What if anything is expected of the producer in terms of how long to store events?
Sounds like it. But the compaction section has more details - basically you can discard events that are overwritten by later ones
Did someone just reinvent a GET API with cursor-based pagination?
This is an astonishingly bad idea. Don't do this.
Use HTTP server-sent events instead. Those can keep the connection open so you don't have to poll to get real-time updates and they will also let you resume from the last entry you saw previously.
https://developer.mozilla.org/en-US/docs/Web/API/Server-sent...
Yeah, but in real life, SSE error events are not robust, so you still have to do manual heartbeat messages and tear down and reestablish the connection when the user changes networks, etc. In the end, long-polling with batched events is not actually all that different from SSE with ping/pong heartbeats, and with long-polling, you get the benefit of normal load balancing and other standard HTTP things
Correct. In the end, mechanically, nothing beats long polling. Everything ends up converging at which point you may as well just long poll.
Or use Braid-HTTP, which gives you both options.
(Details in the previous thread on HTTP Feeds: https://news.ycombinator.com/item?id=30908492 )