TLDR: Nimbus now has a native RabbitMQ transport. Details and docs here.

In the beginning, Nimbus only spoke Azure Service Bus. If a project needed RabbitMQ we reached for MassTransit, which is excellent, and got on with the job.

These days everybody supports everything, so for completeness I’ve added a native RabbitMQ transport to Nimbus. If you’ve used the other transports there’s nothing new to learn. Your code is the same, with a different transport config.

The interesting part of this work was LavinMQ, which I’ve only recently become aware of.

LavinMQ is a RabbitMQ-compatible broker written in Crystal, built by the team at 84Codes. It speaks AMQP 0.9.1, the same protocol as RabbitMQ, so the Nimbus transport works against it unchanged. I built and tested the transport against a LavinMQ broker as well as Rabbit.

Moving an existing app across is literally a connection string change.

LavinMQ is interesting

From what I have learned, LavinMQ is written to be leaner and faster than RabbitMQ. It uses a whole lot less RAM, and has a much lower latency than RabbitMQ.

It’s also got a nice, modern web interface which makes monitoring it easy.

LavinMQ doesn’t have the plugin ecosystem that Rabbit does, or some of the routing and federation options, but it does come bundled with a few things you need that are options in Rabbit. The one I care most about is delayed messages, which is baked in and you don’t need to do a thing to use it with Nimbus.

There’s another cool feature baked in that has given me some ideas, a Shovel feature which will forward messages via HTTP. An interesting option for some integration scenarios.

The other thing to think about if you’re getting started, is that the 84Codes team run CloudAMQP and offer hosting for both Rabbit and LavinMQ, so you can outsource that pain and just get started.

RabbitMQ support is out now for Nimbus. If you try it, especially against LavinMQ, let me know how it goes.