from Hacker News

RCP 11 – Stream data type proposal for Redis

by neo2001 on 6/5/16, 10:06 AM with 16 comments

  • by judofyr on 6/5/16, 12:16 PM

    Yes, please. I've never understood why someone wants to do pub/sub and only base the reliability on TCP/WebSockets. The concept of "fire and hope everyone who wants the message still has a connection open" always seemed fragile to me.

    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.

  • by dunkelheit on 6/5/16, 2:17 PM

    That's cool. In case you haven't seen this blog post [1], it provides an extended discussion of the uses of this abstraction.

    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....

  • by sintaxi on 6/5/16, 12:13 PM

    Salvatore is a machine. Since 2012 Redis has been a main tool in my preverbal belt and it has always seemed to have forward momentum.

  • by thesorrow on 6/5/16, 5:31 PM

    Apache Kafka is a beast. Would be awesome to have a light alternative !

  • by louthy on 6/5/16, 8:10 PM

    This looks very interesting. I use Redis as a backend for an actor-system [1] as part of a larger functional framework for C# [2]. I use RPUSH to add messages to an actor's queue along with PUBLISH for saying 'new message' to the actor that should check its inbox, this is then followed by LINDEX 0 to peek at the item at the head of the queue, before calling LPOP when the message has been successfully processed. If I'm understanding this correctly, that process could be wrapped up in a single stream?

    [1] https://github.com/louthy/language-ext/tree/master/LanguageE...

    [2] https://github.com/louthy/language-ext