DandyRabbitMQ.Consumer 10.0.0

What is DandyRabbitMQ?

DandyRabbitMQ is a framework that offers comfort features and facades for the original client API RabbitMQ.Client by Broadcom. The goal is to make the use of RabbitMQ.Client significantly easier, avoid boilerplate and streamline communication.

Setup and packages

DandyRabbitMQ comes with multiple packages. Often frameworks with a large amount of packages can easily confuse. This section's goal is to make the dependency graph of the packages, and more importantly what packages you need in what case, more transparent. Also, this section is supposed to show you how to setup the framework in both consumer and/or producer applications.

Package dependencies

The following UML package diagram shows the dependency graph of all current packages.

• DandyRabbitMQ.Core contains connectivity concerns, message abstractions and attributes for messages.
• DandyRabbitMQ.Serialization contains abstractions for serializing a messages payload
• DandyRabbitMQ.Serialization.SystemTextJson and DandyRabbitMQ.Serialization.NewtonsoftJson contain implementations of the payload serialization abstractions with respective serialization frameworks
• DandyRabbitMQ.Consumer contains a message consumption worker and consumer abstractions for consuming messages
• DandyRabbitMQ.Producer contains message production and dispatching

Packages for producers

Producer will need to reference only DandyRabbitMQ.Consumer and any of the serialization implementations, so either DandyRabbitMQ.Serialization.SystemTextJson or DandyRabbitMQ.Serialization.NewtonsoftJson.

This way DandyRabbitMQ.Core and thus DandyRabbitMQ.Serialization are both automatically included. Also, the producer configuration layer allows to configure both serialization and connectivity, so there is no need to add either to your IServiceCollection manually, that is done behind the scenes.

Setup

Only add the producer-specific extension for the IServiceCollection, since it give you access to all other configuration APIs of the framework. A setup could look like this:

builder.Services.AddDandyRabbitMQProducer(cfg =>
{
    cfg.Connectivity.ConnectToCluster("dev", "dev", [new Uri("localhost:5672"), new Uri("localhost:5673")], recoveryInterval: null);
    cfg.Connectivity.OnConnectionException((_, ex) => Console.WriteLine($"Exception occurred: {ex}"));
    cfg.Serialization.UseSystemTextJson();
    cfg.Declarations.SubscribeChannel("messages", "consumer-1", channel =>
    {
        channel.Queue.RoutingKeys = ["all"];
    });
    cfg.Messages.ScanInAssemblies(assemblies);
});

Packages for consumers

Producer will need to reference only DandyRabbitMQ.Producer and any of the serialization implementations, so either DandyRabbitMQ.Serialization.SystemTextJson or DandyRabbitMQ.Serialization.NewtonsoftJson.

This way DandyRabbitMQ.Core and thus DandyRabbitMQ.Serialization are both automatically included. Also, the producer configuration layer allows to configure both serialization and connectivity, so there is no need to add either to your IServiceCollection manually, that is done behind the scenes.

Setup

Only add the consumer-specific extension for the IServiceCollection, since it give you access to all other configuration APIs of the framework. A setup could look like this:

builder.Services.AddDandyRabbitMQConsumer(cfg =>
{
    cfg.Connectivity.ConnectToCluster("dev", "dev", [new Uri("localhost:5672"), new Uri("localhost:5673")], recoveryInterval: null);
    cfg.Connectivity.OnConnectionException((_, ex) => Console.WriteLine($"Exception occurred: {ex}"));
    cfg.Serialization.UseSystemTextJson();
    cfg.Declarations.SubscribeChannel("messages", "consumer-1", channel =>
    {
        channel.Queue.RoutingKeys = ["all"];
    });
    cfg.Messages.ScanInAssemblies(assemblies);
});

Use of AI

This section briefly outlines how AI was used for writing this framework. If an aspect if writing is not mentioned down below, it wasn't done using AI.

Unit tests

Unit tests have been partially written by AI. Specifically pay attention to the term written, since the test design was still man-made. The tests were planned with simple comments (such as // Create_SettingType_BasicPropertiesTypeNotOverwritten). Copilot was them prompted to implement the tests. Afterwards the tests were read manually and run manually. If needed adjustments were made.

Documentations

The XML-Documentation of the code was entirely generated by AI. Copilot was prompted iteratively to write the documentation and then asked to adjust until the result was satisfactory.