This has been the reason I've recommended implementing long-polling instead of WebSockets for real-time applications. And every time I see a real-time solution which only uses WebSockets I try to steer away from it. Once you have a reliable data model (which includes log position, retrieving old messages etc.) it's just as simple to implement long-polling as WebSockets. With WebSockets-only solution I can't help but think they base all the message delivery reliability on TCP.
This proposal looks like a clean (very Redis-like) solution, and I immediately see use cases for it.
The browser handles the log position for you (via the id field and the Last-Event-ID header) and automatically reconnects when the server closes the stream or the connection is lost.
The proposed Redis API seems to fit extremely well to this model. My previous usage of EventSource with Redis worked by sending the entire state whenever someone (re-)connects and using PubSub afterwards. This works well for me, but likely doesn't scale very well.
If you dont need bi-directional realtime messaging, use SSE.
It's exciting to see a proposal for an all-Redis implementation.
One comment about the groups API is that while it is very convenient, it seems a bit fragile - if a consumer is nuked immediately after it gets a fresh batch from redis then this batch is lost forever.
[1] https://engineering.linkedin.com/distributed-systems/log-wha....
Edit: Not asking to be a jerk or insist that s/he donate. I use lots of things heavily that I've never contributed to. I'm just curious how the Redis community works.
I'm not familiar with the Redis dev process at all. How long might one expect it to take for a feature of this complexity to make it from RCP to production-ready?
[1] https://github.com/louthy/language-ext/tree/master/LanguageE...
