Newest first, grouped by year. Search or filter by topic.
Convey.WebApi.CQRS wires HTTP verbs straight to command and query dispatchers - one line per endpoint - and publishes your message catalog at /_contracts. A source read of the thinnest HTTP layer I've shipped to production.
Convey.WebApi threw away controllers, replaced every MVC formatter with its own, and bound route values into immutable commands by writing to compiler-generated backing fields. A source read of a routing layer built years before .NET shipped the same idea.
How Convey wraps every command and event handler with template-driven logging using one attribute, a Scrutor decoration — and a reflection trick against Scrutor itself that I admire and would never ship.
The hundred lines of code that let an entire microservices toolkit compose from one fluent chain — a named registry, a list of build actions, and two hard lessons about doing work at startup.
Convey's CQRS layer is small enough to read in one sitting — commands, queries and events as empty interfaces, Scrutor scans to find handlers, and a scope-per-dispatch decision with consequences worth knowing before production.
Every team's fifth microservice ships with the same four hundred lines of bootstrap code as the first four. Opening a deep-dive series on Convey, the open-source .NET toolkit that turned that boilerplate into thirty composable packages.
Chronicle ships two persistence integrations, and reading them against the contract is a masterclass in provider sharp edges: a Redis key built from Type.GetHashCode() that changes on every restart, a Mongo delete-then-insert, and messages that may not survive the round trip.
Eight parts of source-reading later, the honest retrospective. What Chronicle gets right, the timeout-shaped hole at its centre, how it stacks up against MassTransit and NServiceBus and durable execution - and the cases where a status column beats every saga framework ever written.
Chronicle's persistence surface is two interfaces - a state repository and an append-only log - and the defaults behind AddChronicle() are two Lists. What the contracts really demand, why the in-memory implementations are sharper than they look, and how to write a provider that holds up.
When a Chronicle saga rejects, the saga log is replayed backwards and every handled message gets its CompensateAsync called. Tracing both rejection paths through the source reveals a surprise - only one of them actually compensates - plus a ForEach that never awaits.
Seeker, initializer, processor, post-processor - Chronicle's whole runtime is four internal classes you can read in ten minutes. A source walk through the pipeline, including the gate that drops messages, the finally block that always persists, and the state that isn't as final as it looks.
services.AddChronicle() registers sagas you never mentioned, and one ProcessAsync call can run five of them in parallel. Inside Chronicle's Scrutor scan, the seeker's dedupe trick, and the ref-counted lock that serializes each saga id.
Correlation is the part of the saga pattern that fails silently. SagaId, SagaContext, the Empty-context trap that starts a new saga per message, and the one-method override that routes messages by their own content.
Split one database into five services and the transaction you deleted does not disappear - it goes feral. On sagas, compensation, process managers, and Chronicle, the small open-source .NET library this series reads line by line.
Chronicle's entire programming model is Saga<TData>, ISagaStartAction, and ISagaAction. Building a full order-fulfilment saga to learn what Complete() promises, what Reject() actually does, and why a saga can have more than one beginning.
After sixteen parts inside the source, the honest retrospective - what the library gets right, the sharp edges that will cut you (singletons, statics, magic), and the projects where I would leave it on the shelf. Part 17, the conclusion of FastEndpoints in Depth.
The cross-cutting drawer of FastEndpoints holds a rate limiter that documents its own limitations, idempotency built on output caching, server-sent events - and a full implementation of the x402 micro-payments protocol. Part 16 of FastEndpoints in Depth.
Everything FastEndpoints does with reflection - discovery, setters, factories - has a compile-time twin in its source generators, and following that migration is a case study in making a reflection-heavy library AOT-ready. Part 15 of FastEndpoints in Depth.
FastEndpoints ships a testing package where tests call endpoints by class name, apps boot once per fixture, and even command handlers can be faked - the route string never appears in a test. Part 14 of FastEndpoints in Depth.
FastEndpoints' job queues persist commands through a storage provider you supply and execute them with a semaphore design that idles without polling. The state machine in JobQueue.cs is worth the read on its own. Part 13 of FastEndpoints in Depth.
FastEndpoints.Messaging.Remote executes the same ICommand on another machine over gRPC, serialized with MessagePack instead of protobuf contracts - plus an event hub mode that turns a server into a lightweight broker. Reading it explains both the magic and the trade. Part 12 of FastEndpoints in Depth.
FastEndpoints ships in-process messaging that covers most MediatR use cases - events with three wait modes, commands with middleware pipelines, generic and streaming handlers. The dispatch code makes some sharp lifetime choices worth knowing. Part 11 of FastEndpoints in Depth.
FastEndpoints' Swagger support is a thousand-line translation layer that knows which DTO properties are route params, which FluentValidation rules are schema constraints, and which endpoint versions belong in which document. Part 10 of FastEndpoints in Depth.
FastEndpoints suffixes versions by default - /api/orders/v2 - and its release-group model versions endpoints, not APIs. Reading the route-building code explains the philosophy, and the AspVersioning bridge covers everyone it doesn't fit. Part 9 of FastEndpoints in Depth.
The FastEndpoints.Security package covers the token lifecycle end to end - creation with symmetric or RSA keys, an abstract refresh-token service that is secretly an endpoint, and a revocation middleware that makes you pay the lookup tax honestly. Part 8 of FastEndpoints in Depth.
