DEV Community: Andrea Ficarra

AnyMediator: the MediatR programming model, with tracing and notification sinks built in

Andrea Ficarra — Sun, 01 Nov 2026 16:02:46 +0000

Requests, handlers, pipeline behaviors, notifications: the mediator pattern as MediatR popularized it is a comfortable way to structure a .NET application. After using it on several projects, I kept adding the same things around it: tracing, a way to send some notifications to a message broker, a check that no request had two handlers.

AnyMediator is the result: an in-process mediator with the same type names and configuration API as MediatR, and those things built in. This post shows what it looks like and what it adds.

Disclosure: I am the author.

The basics look familiar

dotnet add package AnyMediator

builder.Services.AddAnyMediator(cfg =>
{
    cfg.RegisterServicesFromAssemblyContaining<Program>();
    cfg.AddOpenBehavior(typeof(ValidationBehavior<,>));
});

public sealed record GetUser(int Id) : IRequest<UserDto>;

public sealed class GetUserHandler(AppDbContext db) : IRequestHandler<GetUser, UserDto>
{
    public async Task<UserDto> Handle(GetUser request, CancellationToken cancellationToken)
        => await db.Users
            .Where(u => u.Id == request.Id)
            .Select(u => new UserDto(u.Id, u.Name))
            .SingleAsync(cancellationToken);
}

app.MapGet("/users/{id}", (int id, ISender sender) => sender.Send(new GetUser(id)));

IRequest, IRequestHandler, INotification, INotificationHandler, IPipelineBehavior, ISender, IPublisher, IMediator, stream requests, pre/post-processors, exception handlers and actions: if you know MediatR, you already know the API. It targets .NET 8 and .NET 10.

Tracing without writing a behavior

Every Send, CreateStream and Publish is a span, and every notification handler is a child span, through .NET's own ActivitySource. Add the source to OpenTelemetry and they appear in your traces:

builder.Services.AddOpenTelemetry()
    .WithTracing(t => t
        .AddSource(AnyMediatorDiagnostics.ActivitySourceName)
        .AddAspNetCoreInstrumentation()
        .AddOtlpExporter())
    .WithMetrics(m => m
        .AddMeter(AnyMediatorDiagnostics.MeterName)
        .AddOtlpExporter());

A request to GET /users/42 then shows the ASP.NET Core span, send GetUser under it, and the database spans under that. A failure sets the span status to Error with the exception, following the OpenTelemetry conventions. The anymediator.operation.duration histogram gives the duration, count and failures per message type.

There is nothing to install and no option to turn on. With nobody listening, the cost is a couple of flag checks.

Notifications that leave the process

Publish hands each notification to every registered INotificationSink. The default sink runs your in-process handlers; add another one and the same Publish also reaches a message broker, a webhook or an outbox:

public sealed class ServiceBusSink(ServiceBusSender sender) : INotificationSink
{
    public Task Dispatch<TNotification>(TNotification notification, CancellationToken cancellationToken = default)
        where TNotification : INotification
        => sender.SendMessageAsync(
            new ServiceBusMessage(BinaryData.FromObjectAsJson(notification)) { Subject = typeof(TNotification).Name },
            cancellationToken);
}

builder.Services.AddSingleton<INotificationSink, ServiceBusSink>();

Handlers do not know or care where else the notification goes. Every sink runs even if an earlier one fails, and the failures reach the caller afterwards.

Mistakes caught at startup

If assembly scanning finds two classes handling the same request, AddAnyMediator throws and names both of them, instead of picking one silently. The usual culprit is a test double left in a scanned assembly, and it is much nicer to find out when the app starts than when a request returns the wrong result.

When a request has no handler at all, the error message says which interface to implement and which assembly to scan.

Fast where it counts

BenchmarkDotNet on .NET 10, one handler, no behaviors, each library with its default registration:

Library	`Send`	Allocated	`Publish`	Allocated
MediatR 12.5.0	92 ns	200 B	145 ns	288 B
AnyMediator	86 ns	96 B	90 ns	80 B
Mediator 3.0.2 (source generated)	11 ns	0 B	18 ns	0 B

Dispatch goes through small generic wrappers built once per message type, so there is no reflection after the first call. Martin Othamar's Mediator is in another class thanks to its source generator; for a request that touches a database or the network, none of these differences is measurable.

Coming from MediatR

Handlers and behaviors compile unchanged. The migration is the package, the namespaces and the registration call:

- using MediatR;
+ using AnyMediator;

- services.AddMediatR(cfg =>
+ services.AddAnyMediator(cfg =>
  {
-     cfg.LicenseKey = "...";
      cfg.RegisterServicesFromAssemblyContaining<Program>();
  });

The migration guide lists the few differences, and the docs home page has a converter you can paste your Program.cs into. AnyMediator is Apache-2.0, with no license key.

When to pick something else

Native AOT, or every nanosecond counts: Mediator and its source generator.
Queues, retries and durable messaging as a framework: Wolverine.
Happy with MediatR as it is: no reason to move.

The docs have a side-by-side comparison of AnyMediator, FreeMediator, MediatR, Mediator, LiteBus and Wolverine, with sources.

One container to replace Grafana + Loki + Tempo + Prometheus

Andrea Ficarra — Mon, 25 May 2026 20:25:26 +0000

The standard observability stack:
Grafana + Loki + Tempo + Prometheus. Four services to deploy, four configs to learn, dashboards to set up before you see a single trace.

What I actually needed:
One place to see traces, logs, and metrics from my services.

What I built:
One container. docker compose up. Done.

I work with .NET microservices and at some point I went through the full Grafana setup. And look, it works fine, it's a solid stack. But for what I needed it was way too much. I spent more time configuring things than actually looking at my data. The .NET Aspire dashboard is on the other end: you get a nice UI, but nothing is persisted. Close the browser and everything's gone. No customization either.

So I built something in between.

What it is

OtlpDashboard is a single container that receives OpenTelemetry data and stores it. It speaks standard OTLP on port 4317 (gRPC) and 4318 (HTTP/Protobuf). If your app already exports telemetry, you just point it here. No collector needed (works behind one too if you already have it).

Storage is SQLite by default, so zero config, just a file. You can switch to PostgreSQL or SQL Server if you want.

The frontend is a Vue 3 / Nuxt 4 SPA served on the same port. You get a grid of widgets you can customize: stat cards, line charts, sparklines, gauges, heatmaps, log streams, trace viewers, and a few more. Auth is on by default.

How AI helped me ship this in under a month

I want to be upfront about this. I used Claude Code a lot, especially for the frontend. I'm a backend dev. I know .NET, EF Core, gRPC. But Vue and Nuxt? Not really my thing. Without Claude Code I would have spent days stuck on CSS and component wiring. Instead I could focus on what I actually care about: the OTLP ingestion, the storage layer, how widgets work.

All the architecture and decisions are mine. The AI did the typing.

And honestly, I think that's the best use of these tools right now if you're a solo dev. They don't replace you. They cover the parts where you're slow, so you can ship something that would normally need a small team.

Some stuff I like about how it turned out

You can install widget packs from Git repos. There's a pack.json that bundles widgets and dashboards together, so if you have a team you can share a curated setup.

There's also a spec engine for building custom widgets with Mustache templates. It's sandboxed with DOMPurify, no JS eval. I wanted people to be able to build their own cards without opening security holes.

Retention is configurable per signal. Set 7 days for traces, 30 for metrics, whatever you want. Old data gets cleaned up on its own.

And there's an MCP server at /mcp if you use Claude Code or similar tools. You can query your telemetry from the LLM directly. I didn't expect to use this much but it's actually pretty handy when debugging.

Try it

Quickest way:

docker compose up --build

This starts everything including a sample workload that generates real data, so you're not staring at an empty dashboard.

Or just check the live demo. It's a static build with mock data, login accepts any password: Live demo

The repo is here: GitHub

It's GPLv3. If you try it out let me know what you think, I'm curious what's missing or broken.