Brighter: a Command Dispatcher and Command Processor for .NET Messaging

The problem Brighter solves for C# teams

Most .NET applications start with a service class that calls other service classes. That works until the call graph gets deep, at which point logging, retries and transaction boundaries get copy-pasted into every method. Brighter's answer is the Command pattern: a command is a small object that describes an intent, a handler owns the logic for that intent, and a dispatcher routes the command to the handler. The README describes Brighter as a "Command Dispatcher and Command Processor framework for .NET" and positions it for "loosely coupled, maintainable applications" and microservices. The audience is narrower than that phrasing suggests. Brighter is for teams already comfortable with dependency injection in Microsoft.Extensions.Hosting, because the quick start builds a Host and resolves IAmACommandProcessor from the service provider. If your application is a single console tool with no DI container, the setup cost is real and the payoff is small. The companion project Darker handles the query side of CQRS, which tells you the authors expect you to split reads from writes rather than treat Brighter as a general-purpose service bus.

How the dispatcher, pipeline and transports fit together

Three layers are visible in the README. The first is the command processor. You call Send for in-process dispatch or Post to publish to an external broker, and both go through the same IAmACommandProcessor interface. The second is the handler pipeline. Handlers derive from RequestHandler<T> or RequestHandlerAsync<T>, and cross-cutting behaviour is attached with attributes on the Handle method. The README shows RequestLogging with a step and timing, and UseResiliencePipeline with a step, which means ordering is explicit and numeric rather than implied by declaration order. That is a design choice worth noting: it makes pipeline order readable in the source, but it also means reordering middleware is a code edit on every handler rather than a configuration change. The third layer is the transport. Producers are registered through a producer registry built from a connection object, and consumers are registered as subscriptions with a subscription name, channel name, routing key and message pump type. The sample consumer uses MessagePumpType.Reactor and OnMissingChannel.Create, so channel creation can be delegated to the library at startup. Nothing in the README describes a broker-side routing engine; the routing key and channel name you supply are passed to the broker as-is.

Installing Brighter and sending a first command

Brighter ships as NuGet packages and targets .NET 8, 9 and 10, so the first step is a project on .NET 8 or later. The README's quick start installs the dependency injection extensions together with the generic host:

dotnet add package Paramore.Brighter.Extensions.DependencyInjection
dotnet add package Microsoft.Extensions.Hosting

With those in place, define a command, a handler and a host. The command derives from Command and takes an Id; the handler derives from RequestHandler<T>. The README's example prints a greeting and returns base.Handle(command):

public class GreetingCommand(string name) : Command(Id.Random())
{
    public string Name { get; } = name;
}

public class GreetingCommandHandler : RequestHandler<GreetingCommand>
{
    public override GreetingCommand Handle(GreetingCommand command)
    {
        Console.WriteLine($"Hello {command.Name}");
        return base.Handle(command);
    }
}

Registration is a single AddBrighter call followed by AutoFromAssemblies, which scans assemblies for handlers. Then you resolve the command processor and send:

var builder = Host.CreateApplicationBuilder();
builder.Services.AddBrighter().AutoFromAssemblies();
var host = builder.Build();

var commandProcessor = host.Services.GetRequiredService<IAmACommandProcessor>();
commandProcessor.Send(new GreetingCommand("World"));

Running that should print the greeting to the console. The README notes that asynchronous handlers use RequestHandlerAsync<T> with HandleAsync and SendAsync instead. For out-of-process work you add a transport package, for example Paramore.Brighter.MessagingGateway.RMQ.Async for RabbitMQ, and switch from Send to Post. The repository's docker-compose.yaml starts RabbitMQ on ports 5672 and 15672, which matches the amqp://guest:guest@localhost:5672 connection string in the README example.

Where Brighter is the wrong tool

Brighter does not hide the broker. You supply the exchange name, routing key, channel name and connection URI yourself, and the README's RabbitMQ example hardcodes amqp://guest:guest@localhost:5672 with an exchange named paramore.brighter.exchange. That means the operational surface is the broker's, not Brighter's: if you get the routing key wrong, messages do not arrive, and Brighter has no routing layer to correct you. Teams that expect a framework to own topic provisioning, schema registry integration or dead-letter policy will find those concerns outside what the README documents. The README also does not document rollback, outbox recovery or what happens to in-flight messages when a consumer restarts; the subscription example sets OnMissingChannel.Create, which covers channel creation only. The transport matrix is another constraint. The README lists RabbitMQ, AWS SNS+SQS, Kafka and Redis, and the repository carries separate compose files for MQTT, RocketMQ, MongoDB, Spanner and others, but the README's install commands only name the RabbitMQ, AWS and Kafka packages. If your broker is not among the documented gateways, verify a package exists before designing around it. Finally, the AWS gateway has a version split the README calls out directly: Paramore.Brighter.MessagingGateway.AWSSQS.V4 uses AWS SDK v4, while AWSSQS is for v3. Picking the wrong one is a compile-time problem, not a runtime surprise, but it is a decision you have to make on day one.

Brighter compared with MediatR

MediatR appears in the repository topics, and the comparison is natural because both give you an in-process request dispatcher with a handler pipeline. The difference is scope. MediatR is an in-process mediator: requests and notifications stay inside the process, and if you need a broker you add one yourself. Brighter treats the broker as a first-class concern. The same IAmACommandProcessor that dispatches a GreetingCommand in-process also posts a GreetingEvent to RabbitMQ, and the Service Activator consumes from a queue through a hosted service. That is why Brighter's consumer setup needs a subscription, a channel factory and a ServiceActivatorHostedService, and why the README frames out-of-process messaging as two separate applications. If your system will never leave the process, MediatR is the smaller dependency. If you know you will need a broker, Brighter's advantage is that the handler code does not change when you switch from Send to Post, and the transport is a package swap. The cost is that you configure the transport yourself, and the README's examples put that configuration in startup code rather than in a shared abstraction.

Maintenance, upgrades and the MIT licence

The repository is not archived, and the last push was on 2026-09-28. Releases are frequent: 10.7.0 on 2026-07-29, 10.6.0 on 2026-06-17 and 10.5.1 on 2026-05-21. That cadence matters for upgrade planning, because a three-release quarter means you should expect to move minor versions rather than sit on one for a year. The README states that Brighter targets .NET 8, 9 and 10, so an application on .NET 6 or 7 cannot use current packages without retargeting. Transport packages version separately from the core, and the AWS SDK split between AWSSQS and AWSSQS.V4 shows that a transport upgrade can force a dependency change in your own project. Brighter is MIT licensed, and the repository carries a LICENCE.txt file alongside a CLA.txt and a CODE_OF_CONDUCT.md. MIT is permissive, but I am not giving legal advice: read LICENCE.txt in the repository and confirm it matches what your organisation expects before you depend on it. The CLA file is relevant if your team plans to contribute patches upstream rather than only consume packages.

Editorial conclusion

Adopt Brighter if you are building .NET services that need a command dispatcher today and a message broker later, and you accept that transport configuration is your responsibility. Skip it if you want a broker to do the routing work for you or you need the query side in the same package, since Darker is a separate project. Before committing, check that the transport package you need exists for your broker and SDK version, and confirm the licence file in the repository matches what your legal review expects.

Frequently asked questions

Official sources

1. BrighterCommand/Brighter on GitHub
2. License: MIT
3. Project website
4. README
5. Releases