It’s a nifty little tool with a silly label, but since it implements queues on top of MongoDB, the name was inevitable! 🤠
So, if all you have in the world is MongoDB, and you want to do some messaging, you can do this:
var config = new Config("mongodb://MONGOBONGO01/some-db", "messages");
to create a configuration, and then you
var producer = config.CreateProducer(); var message = new Message(Encoding.UTF8.GetBytes("hei")); await producer.SendAsync("destination-queue", message);
to send a UTF8-encoded text to a queue named
destination-queue, and then you
var consumer = config.CreateConsumer("destination-queue"); var message = await consumer.GetNextAsync(); // ... handle message here
to receive the message and handle it.
You can read more about it on the GitHub page, and you can get the binaries from your favorite package repository.
And why would one want to use MongoDB instead of real message queues?
It started out as a genuine need for a message queue that supported arbitrarily large payloads with a disconnected API (i.e. connection-less receive protocol, with completely separated receive/ACK operations). Fleet Manager uses it internally to support sending commands to Rebus endpoints, which in turn query for messages via long-polling.
Also, sometimes databases are just nice. They can do lots of stuff that message brokers can’t, so if your throughput requirements are modest, and you happen to have a MongoDB lying around, then maybe MongolianBarbecue is for you? 🤓
About the author