Cloud Solution Design : MediatR Middleware (With components examples)

Series of posts based around building a cloud solution from scratch covering topics for beginners up to intermediate level .NET developers.

Small disclaimer this series of posts are about me showing you where from you can learn practices and which ones are going to bring you value.

Purpose of this story : show different kinds of middleware components that might be useful to developers.

For starters readers would need to get to know with what a middleware pipeline is, you can read about it from the following links:

• Documentation : official docs are explaining the topic pretty much.
• For readers familiar with Russian language following this post will be of interest to you.
• Since MediatR is taking its fair share of market these days we are going to go over some example of middleware implemented inside its own execution pipeline. (Which in my opinion is somewhat easier to understand for begginners rather than the .net native one)
• Any ideas inspired from middleware components can be rewritten to the .net native middleware because in essence the idea is the most important thing here.

A bit of lyrical digression, one of my friends once said :

“Not all systems have a well defined request/response pipeline, but every mature enough system will surely have one.”

What I’m planning is to show you a couple of middleware components that we use a lot.

The following components of the pipeline will be looked over in this story:

1. Request logger : a component that will log the start of a MediatR request.
2. Request performance component : a component that will log the performance of long running requests.
3. Request exception wrapper : a component that will ensure that even if the request fails with an exception a structured response is going to be returned to the caller.
4. Request retry component : a component that will use polly and a marker interface to retry specific failed requests for a number of time.

Let’s get it started then. First off I’ll show you the boots-trapper where I configure the order of the middleware components.

MediatR pipeline bootstrapper.

Next is the Request Logger and here is the code for the logger:

Request performance logger.

Next is the Request Exception Wrapper, and a small disclaimer is the fact that we are using the Result<T> format for action responses throughout the application, so when using this middleware component we are sure that we don’t get any flow breaking exceptions in our code.

Request exception wrapper.

Next is the Request retry component, this is a bit more interesting as this is a component that is using Polly as well. So for starters we have a marker Interface, which the requests that need a retry policy can inherit from, as well we have options where we can specify the number of retries etc.

And here is some code for a retry component that can serve as a place to start:

Retry middleware component.

So these are just a couple of standard components that I would use in the applications I’m developing. This will give me insight on the performance of specific queries, allow me not to worry that the flow that is running at any point of time will be stopped midway due to an exception, and give me the option of marking specific requests as ready for retry in case of some transient failures.