Any Good Message Brokers or Queue Systems?

Learn
#1

Hi all,
I am looking for a good message broker service with solid haskell bindings. I have a need for maintaining multiple topics that can be published/subscribed by various systems locally or over network. I don’t want to use any cloud services because my use case is just inter process communication, making the whole cloud thing more of a pain than any real benefit.

Currently I am looking into RabbitMQ, ZeroMQ, and anything else mentioned in the ZeroMQ wiki page, but if anyone has any recommendations please send them my way.

1 Like
#2

Kafka has a lot of market share. And has a good haskell library.

4 Likes
#3

RabbitMQ has served us well enough. :man_shrugging:

The amqp library does what you want it to do. You might need to read up on how RabbitMQ works in general, but it’s been super stable and performant for us so far :+1:

5 Likes
#4

For IPC, ZeroMQ is a work of art and their pub-sub examples page needs some Haskell additions too ^^

2 Likes
#5

RabbitMQ works well at my workplace, only when we get above 500M messages in a queue we start to get in trouble (fairly beefy on premise server).

I haven’t tried using it from Haskell yet (for my personal stuff PostgreSQLs NOTIFY/LISTEN has been sufficient so far).

3 Likes
#6

Thanks for the response. I think kafka is a bit over kill for my use case

#7

Yeah it looks like this will end up being the choice. It’s lightweight and has a ton of support. Not much more you can ask for I suppose

#8

Another happy RabbitMQ + amqp user here

3 Likes
#9

Kafka has worked well with the mentioned Haskell library

#10

I’ve also used RabbitMQ happily in the past!

I’d also like to mention that Kafka is a distributed event store / stream processing platform. It is not a message broker. If you try to use it as if it were a message broker, you’ll end up implementing some basic primitives from scratch and depending on what your exact requirements are you might have a very bad time. Kafka’s topics do not have message queue semantics.

3 Likes
#11

Kafka is just way too much for my use case. I ended up going with zmq as it seems the most lightweight. I will be processing hundreds of events at most, and will only have like 6 sources at most.

Using a pub/sub zmq pattern along with some basic req/res seems to be doing the trick. The zmq haskell library is also fairly ergonomic, which was a pleasant surprise.

#12

We’ve used RabbitMQ in the past with good results.

1 Like