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