HareDu Resources

HareDu resources encapsulate the concept of manipulatable entities in RabbitMQ. For a developer's perspective

What you'll notice is that each resource , no matter its type, has at least the following methods: GetAllAsync, CreateAsync, and DeleteAsync. For the most part, HareDu 2 sticks to this pattern but there are exceptions to this when it makes sense to deviate. For example, the Queue resource has other methods such as PeekAsync and EmptyAsync. With that said, let's dive in.

Before you do anything, you need to initialize a HareDu client like this...

HareDuFactory client = HareDuClient.Initialize(x =>
{
    x.ConnectTo("http://localhost:15672");
    x.Logging(s =>
    {
        s.Enable();
        s.UseLogger("HareDuLogger");
    });
    x.UsingCredentials("guest", "guest");
});

To understand this in more detail please see the "Configuring HareDu" section in the docs.

Getting a resource is easy...

Queue resource = client.Factory<Queue>();

That's all there is to it. It is worth noting, however, that since the design of the API is fluent, you can combine the above code snippet into a single block. The caveut to chaining method calls in this way would, of course, be determined by your use case. You'd probably would not want to do this in a real scenario because the Factory method will initialize the resource every time it is called, which is why you'd want to call this once within your scope. HareDu resources are stateless. Put simply, they do not have any state at initialization when allows the developer to chain or not chain. It is suggested that you explicitly initialize it separately then call necessary actions against it as seen in the below code snippet.

Queue resource = Client.Factory<Queue>();

Result result = await resource
    .CreateAsync(x =>
    {
        x.Queue("TestQueue");
        x.Configure(c =>
        {
            c.IsDurable();
            c.WithArguments(arg =>
            {
                arg.SetQueueExpiration(1000);
            });
        });
        x.Target(t =>
        {
            t.Node("TestNode");
            t.VirtualHost("HareDu");
        });
    });

What you'll also notice about the about code snippet is that all resources are interface and that you don't have access to the corresponding implementation class. This is done to avoid application accidentally or purposely tampering with the resource factory, avoiding some of the side effects that may come with doing that. If you feel that there is missing functionality please see the section "Contributing to HareDu".

Design Considerations

If you are familiar with HareDu 1.x, the new API is very much the same in that it did not stray from its fluent roots. However, there are some major difference you should be aware of. In particular, each HareDu resource is standalone, meaning that there is no dependency chain as was the case before. To better understand this consider the use case where you want to create a queue on a particular virtual host.

HareDu 1.x

ServerResponse response = Client
    .Factory<VirtualHostResources>(x => x.Credentials("guest", "guest"))
    .Queue
    .New(x => x.Queue("TestQueue"),
         x =>
             {
                 x.IsDurable();
                 x.WithArguments(y =>
                                     {
                                         y.SetQueueExpiration(1000);
                                     });
             },
         x => x.VirtualHost("HareDu"))
    .Response();

HareDu 2

Result result = await Client
    .Factory<Queue>()
    .CreateAsync(x =>
    {
        x.Queue("TestQueue");
        x.Configure(c =>
        {
            c.IsDurable();
            c.WithArguments(arg =>
            {
                arg.SetQueueExpiration(1000);
            });
        });
        x.Target(t =>
        {
            t.VirtualHost("HareDu");
        });
    });

Notice that in HareDu 1.x you have to get the Virtual Host resource--passing user credentials--before you can get the Queue resource to perform a queue create action. In HareDu 2, however, you can perform an action directly off of a Queue resource. This behavior can therefore, be described as standalone, in that resources do not require other resources be instantiated in order perform actions against them.