[HN Gopher] RabbitMQ Streams Overview
       ___________________________________________________________________
        
       RabbitMQ Streams Overview
        
       Author : DeadTrickster
       Score  : 84 points
       Date   : 2021-07-13 20:28 UTC (2 hours ago)
        
 (HTM) web link (blog.rabbitmq.com)
 (TXT) w3m dump (blog.rabbitmq.com)
        
       | gbrits wrote:
       | This seems comparable to redis streams. How is it different?
        
         | adamcharnock wrote:
         | You are right that these are very comparable. A few years ago I
         | was very experienced in both as I created Lightbus
         | (lightbus.org).
         | 
         | From what I can still recall, AMQP (RabbitMQ) looked great to
         | me until Redis Streams came along. RabbitMQ always seemed more
         | heavyweight in various ways, whereas Redis Streams was very
         | easy to pickup and get going with.
         | 
         | Redis Streams isn't simple, but I always found RabbitMQ to be
         | more complex and to have more gotchas.
        
       | nodejs_rulez_1 wrote:
       | Is RabbitMQ something industry used to use before AWS/Azure
       | queues?
        
       | james_in_the_uk wrote:
       | Where's the illustrated children's book? Rabbits vs otters. :)
        
       | annnoo wrote:
       | This is really interesting for small scale projects.
       | 
       | If you are a solo Dev and really want/ need data streams than you
       | can only chose between Kafka and Redis Streams at the moment.
       | While there are a lot of client libraries for Kafka for nearly
       | every programming language, you really don't wanna manage your
       | own Kafka instance and, to be fair, it really feels like
       | overkill.
       | 
       | So RabbitMQ seems to fit into the same spot as the Redis Streams
       | do: Easy manageable and usable streams, even for smaller
       | projects. Really hope that this will be usable in many different
       | client libraries soon.
        
         | abledon wrote:
         | can you give some examples why i'd want a data stream for a
         | 'small scale project' ?
        
           | debrice wrote:
           | Integration and webhooks are very well suited for streams.
           | Having your core product emitting messages as event have many
           | benefits:
           | 
           | - You can have a team working on the core product sending
           | messages and another working on integrations triggering
           | actions.
           | 
           | - If your integrations fails, your core product is not
           | impacted. You can also replay old messages once you've fixed
           | the stream consumer.
           | 
           | - Having streams allows you to do all kind of experiments
           | too, you can connect a new project to a stream and go through
           | a week of data almost instantly and see the result... rince
           | and repeat as much as necessary
        
         | piyh wrote:
         | >you really don't wanna manage your own Kafka instance
         | 
         | So much of my life would be better right know if you didn't
         | just describe me.
        
           | jng wrote:
           | Care to provide some details on this?
        
             | Redsquare wrote:
             | Probably because....zookeeper
        
       | tetha wrote:
       | Mh, this seems useful for our internal discussions of kafka vs
       | rabbitmq, and might make some of the stuff we do with rabbitmq
       | easier or more effective. Neat.
       | 
       | So, I'm taking bets how many days it takes until some teams
       | decide that any further development is impossible without this
       | feature. Yes, it's been a long day.
        
         | Spivak wrote:
         | Once you know that your ideal tool exists it's super super
         | shitty to implement half-baked workarounds that you know will
         | get deleted in the next upgrade cycle.
         | 
         | I for one on the ops side will be pushing to upgrade ASAP
         | because the sooner devs adopt this the sooner I can tear down
         | Kafka and have one less thing to maintain.
        
       | DeadTrickster wrote:
       | TLDR: RabbitMQ 3.9 introduces new data/queue type which is
       | backwards compatible with existing amqp 0.9.1-based clients but
       | gives enormous performance boost when used via new custom streams
       | protocol. Oh and it's replicated/persistent too.
       | 
       | For example, on the test 3-node cluster (c2-standard-16) it
       | achieved publish rate of almost 5 millions messages per second.
        
         | growup12345 wrote:
         | It's not a queue but an append only log
        
           | exdsq wrote:
           | I thought append only logs required crypto tokens to use
           | nowadays?
        
           | saltedonion wrote:
           | Redis too have an append only log at-least for backup and
           | persistence. What's the difference with rabbitmq?
        
       ___________________________________________________________________
       (page generated 2021-07-13 23:00 UTC)