Messaging plays a crucial role in enabling loosely coupled and scalable architectures. MassTransit and RabbitMQ provide a powerful combination for building reliable and robust messaging systems. In this post let’s explore an example of how to implement messaging in .NET leveraging these technologies.
MassTransit
Just to bring some context, let’s start with a brief introduction to MassTransit.
MassTransit1 is an open-source distributed application framework for .NET. It simplifies the development of message-based applications by providing abstractions and utilities for building robust, scalable, and loosely coupled systems. MassTransit supports multiple transport providers, including RabbitMQ, Azure Service Bus, and more. It also provides support for various messaging patterns like publish/subscribe, request/response, and routing.
RabbitMQ
Similar to MassTransit, here’s a brief introduction to RabbitMQ.
RabbitMQ2 is a popular open-source message broker that implements the Advanced Message Queuing Protocol (AMQP). It provides a reliable and scalable messaging infrastructure with support for various messaging patterns like publish/subscribe, request/response, and routing. RabbitMQ3 acts as the backbone for MassTransit, handling the reliable delivery of messages between producers and consumers.
The example
Docker compose
RabbitMQ will run on a docker container. The following docker-compose file4 will be used to spin up the container.
This solution uses docker, but if you prefer, you can use a SaaS RabbitMQ provider like CloudAMQP.
The entity and events
The example will use a simple entity called Product and two record events ProductCreatedEvent and ProductUpdatedEvent. The ProductCreatedEvent event will be published when a product is created, and the ProductUpdatedEvent event will be published when a product is modified/updated.
The Publisher, which is an API, will expose three endpoints, the first for creating a product, the second for updating a product, and the third for scheduling a product creation. The endpoints will publish the corresponding event to RabbitMQ.
To start, this is how the middleware is initialized:
NOTE: Consumers are added to the container, and the QueueProductCreatedConsumerDefinition and QueueProductUpdatedConsumerDefinition are used to configure the consumers.
RabbitMQ connection string is retrieved from the appsettings.json file:
The class QueueProductCreatedConsumer implements the IConsumer<ProductCreatedEvent> interface, and the class QueueProductUpdatedConsumer implements the IConsumer<ProductUpdatedEvent> interface.
NOTE: In both consumers, the ConsumerDefinition is used to configure the retry policy, which means that if the consumer fails to process the message, it will retry 3 times with a 5 seconds interval. This could be configured differently for each consumer if needed.
Testing
To test the application, start the Container, then the Publisher and Subscriber projects.
Run the following command to start the docker-compose:
1
dockercomposeup
By using one of the .http requests product-created.http of the Publisher project, trigger it from VStudio:
1
2
3
4
5
6
7
POST http://localhost:7276/api/ProductCreated
{
"id": 1,
"name": "Milk",
"sku": "MILK01"
}
You should be able to see both consoles, Publisher and Subscriber, with the following outputs:
This will be reflected on RabbitMq:
RabbitMQ URL: http://localhost:15672, use guest/guest to log in.
The queued messages will be zeroed, as the messages were consumed by the Subscriber, but you can see a spike on Message rates.
Join the conversation! Share your thoughts and connect with other readers.