Skip to main content

MassTransit–Minimal Message Handlers

By default message handling in MassTransit is done through Consumers. A consumer consumes one or more message types when configured on or connected to a receive endpoint. MassTransit includes many consumer types, including consumers, sagas, saga state machines, routing slip activities, handlers, and job consumers.

With the upcoming 8.1 release, an extra way to handle messages will be "Minimal Message Handlers". Instead of defining a separate Consumer class, a function is provided to handle a given message type, in the trend of the "minimal APIs" feature in ASP.NET Core.

To use this feature, you need to use the AddHandler method on the IBusRegistrationConfigurator:

Of course in this example there is not much happening. Let us extend the example above and log the incoming request message. To inject extra dependencies, we can specify them as extra parameters to the method:

Instead of passing the message directly, we can also use the ConsumeContext to access the message metadata:

If you want to learn more about Minimal Message Handlers, check out this video:

Popular posts from this blog

XUnit - Assert.Collection

A colleague asked me to take a look at the following code inside a test project: My first guess would be that this code checks that the specified condition(the contains) is true for every element in the list.  This turns out not to be the case. The Assert.Collection expects a list of element inspectors, one for every item in the list. The first inspector is used to check the first item, the second inspector the second item and so on. The number of inspectors should match the number of elements in the list. An example: The behavior I expected could be achieved using the Assert.All method:

Azure DevOps/ GitHub emoji

I’m really bad at remembering emoji’s. So here is cheat sheet with all emoji’s that can be used in tools that support the github emoji markdown markup: All credits go to rcaviers who created this list.

Lehman’s Laws of Software Evolution

In the world of software engineering, the Lehman's Laws of Software Evolution are widely recognized as a fundamental framework for understanding how software systems evolve over time. These laws were introduced by British computer scientist, Meir Lehman, in the 1980s(!) in his paper “Programs, Life Cycles, and Laws of Software Evolution”, and they remain relevant to this day. Lehman's Laws describe how software systems evolve and how they can be managed over their lifespan. In this blog post, we will explore these laws in detail and their significance in software development. From the paper : The first law of software evolution states that software systems must evolve or they will become progressively less useful . This law recognizes that software is not static and unchanging, but instead must adapt and grow to meet changing user needs and technological advancements. Failure to evolve software systems can result in decreased usefulness or even obsolescence. This means