Newest first, grouped by year. Search or filter by topic.
Permissions(), Claims() and Scopes() in Configure() feel like magic until you read the mapping code - every endpoint gets its own named authorization policy built from closures at startup, and roles ride a plain AuthorizeAttribute. Part 7 of FastEndpoints in Depth.
FastEndpoints' processors are its cross-cutting hook - but their exact pipeline position, the shared state trick, and a captured exception that waits in a finally block are what make them genuinely useful. Part 6 of FastEndpoints in Depth.
FastEndpoints wires FluentValidation into the pipeline by request-DTO type, runs validators as singletons, and shares one failure list between binder, validator and handler. The lifetime rule is the part that bites. Part 5 of FastEndpoints in Depth.
FastEndpoints binds a single request DTO from JSON, form, route, query, claims, headers, cookies and permissions - in that order, with compiled setters cached per DTO type. Reading the binder explains every binding surprise I have ever hit. Part 4 of FastEndpoints in Depth.
AddFastEndpoints never asks you to register an endpoint. Reading the discovery code shows how a reflection scan over five interfaces becomes a validated endpoint catalogue - and which mistakes it turns into startup crashes on purpose. Part 2 of FastEndpoints in Depth.
Every FastEndpoints route is mapped as a Minimal API whose handler returns the same singleton IResult - and that one weird trick is the door into the whole per-request pipeline. Part 3 of FastEndpoints in Depth.
Controllers grow sideways and Minimal APIs grow into soup. FastEndpoints bets on a third shape - one class per endpoint - and this series reads its source to see how the bet is implemented. Part 1 of FastEndpoints in Depth.
Sync-over-async, a new HttpClient per call, out parameters everywhere - the discovery library needed a rewrite, and dozens of deployed consumers meant it could not break anyone. How the second generation shipped side by side with the first in the same NuGet package, what it fixed, and the one thing it deliberately kept. Part 7 of Service Discovery Without a Service Mesh.
The complete honest ledger for a Key Vault-backed service discovery layer after years in production - the debts I would pay tomorrow, the trade-offs I would sign again, and the concrete signals that it is time to graduate to App Configuration, APIM, Dapr or a mesh. Part 8, the finale of Service Discovery Without a Service Mesh.
The estate's transaction logging wrote to blob storage through a dedicated logging function - which consumers located through the same Key Vault registry the logger belongs to. Discovery consuming discovery, the transaction-id thread that made it useful, and the bootstrap questions self-reference always raises. Part 6 of Service Discovery Without a Service Mesh.
One static registration method wires the whole discovery subsystem into an Azure Functions host, and one CI pipeline packs it as a private NuGet package. The lifetime choices in those few lines quietly decide the caching semantics of the entire estate - and a duplicate registration teaches how DI forgives. Part 5 of Service Discovery Without a Service Mesh.
Above raw resolution sits a convention layer - an abstract endpoint base class that derives its Key Vault lookup key from its own type name, a template method separating the call from the interpretation, and a generic proxy that routes by name across every endpoint the DI container knows. Part 4 of Service Discovery Without a Service Mesh.
Azure Functions want their key in an x-functions-key header; Logic App workflows want a SAS signature in the query string. How a discovery record's type field became a calling-convention discriminator, and how one small HTTP service hid that difference from every caller in the estate. Part 3 of Service Discovery Without a Service Mesh.
The resolution path of a Key Vault-backed discovery client - three fail-fast environment variables, DefaultAzureCredential with a user-assigned managed identity, a name composed as service-plus-environment, a tolerant JSON parser, and a process-lifetime cache with a bug I shipped and honest trade-offs I chose. Part 2 of Service Discovery Without a Service Mesh.
Dozens of Azure Functions and Logic Apps need each other's URLs and keys, and there is no Kubernetes, no sidecar, no mesh to hand them out. How a small .NET library turned one Key Vault and a naming convention into a working discovery layer - the consumer side of a registry made of secrets. Part 1 of a new series.
Retention as a first-class column: how ArchiveKit stamps ExpiresAt at archive time from a TtlDays attribute, hard-deletes expired rows in bounded batches, and runs the whole thing on Lambda with the hosted services switched off. Also, the rows TTL doesn't clean yet. Part 8 of the Archive-on-Delete with ArchiveKit series.
The read side of archive-on-delete: querying archives through promoted typed columns, digging into jsonb payloads for everything else, polling snapshots with a 202 pattern, and an honest accounting of the restore path ArchiveKit doesn't have yet. Part 9 wraps up the Archive-on-Delete with ArchiveKit series.
ArchiveKit's snapshot service assembles a full JSON tree of a deleted object graph using nothing but archive rows - the primary data is already gone. Job tickets, a four-state machine, retries with a terminal Failed state, and the single-table assembly limitation I still owe a fix for. Part 7 of the Archive-on-Delete with ArchiveKit series.
Correlation ids and cascade archiving in ArchiveKit - how one Guid per save turns scattered archive rows into a reconstructable object graph, why cascade happens through the EF change tracker rather than the database, and two honest limits: a naive root heuristic and a CascadeArchive flag the interceptor doesn't read yet. Part 6 of the Archive-on-Delete with ArchiveKit series.
How ArchiveKit wires itself up - the [Archivable] attribute's three knobs, an assembly scanner that fails fast at startup instead of quietly at delete time, the static registry behind every lookup, and the AddArchiveKit configuration surface. Plus an honest note about the source generator that doesn't exist yet. Part 5 of the Archive-on-Delete with ArchiveKit series.
The storage design behind ArchiveKit - typed queryable columns and a jsonb payload from a single write, why the archive's EntityId is an index but deliberately not a foreign key, and the reflective model configuration that builds every archive table from one method call. Part 4 of the Archive-on-Delete with ArchiveKit series.
Why ArchiveKit's inline archive limit defaults to exactly 14, how EF Core's MaxBatchSize turns archiving into arithmetic, and an honest inventory of every deletion path the interceptor cannot see - synchronous saves, ExecuteDelete, and raw SQL. Part 3 of the Archive-on-Delete with ArchiveKit series.
The anatomy of ArchiveKit's SaveChangesInterceptor - detecting soft-deleted entities in the change tracker, building archive rows with zero extra database reads, and the one line of state-flip ordering that keeps EF from cascade-deleting the archive you just wrote. Part 2 of the Archive-on-Delete with ArchiveKit series.
Hard deletes destroy the audit trail; soft deletes clutter live tables forever. Introducing ArchiveKit, a .NET library that intercepts deletions and stores immutable archive snapshots with TTL policies and cascade archiving.
Static registries, Activator-created migrators, a Postgres accent, a flag that does nothing, and no test project - the closing part of the VersionKit series itemises every trade-off in the library, says when you should not use it, and sketches what comes next. Part 10 of the Entity Versioning with VersionKit series.
