Newest first, grouped by year. Search or filter by topic.
FastEndpoints.A2A publishes an agent card at a well-known URL and answers agent-to-agent calls through a JSON-RPC 2.0 dispatcher written entirely by hand - implementing exactly the slice of the A2A protocol it can do honestly. The final missing chapter, and the close of both series. Part 12 of FastEndpoints — The Missing Chapters.
FastEndpoints.Mcp exposes opt-in endpoints as Model Context Protocol tools - schemas generated from your DTOs and enriched from your validators, a synthetic HttpContext that runs the real pipeline, and a visibility model that deliberately ignores your REST auth. Part 11 of FastEndpoints — The Missing Chapters.
FastEndpoints.CommandRules sounds like a Roslyn analyzer and is nothing of the sort - it is a small rules engine that turns an input into planned commands and dispatches each one now or onto a job queue. A close read of the newest package in the repo, capability matrix and all. Part 10 of FastEndpoints — The Missing Chapters.
FastEndpoints will hand you a typed client four different ways - NSwag-generated C# or TypeScript, or Kiota clients built over either OpenAPI stack - served as a download endpoint or produced by a run-then-exit build mode. The lineages, the seams, and one version pin that tells a story. Part 9 of FastEndpoints — The Missing Chapters.
Buried in the FastEndpoints package props is a comment marking NSwag for deprecation - and a whole second OpenAPI stack built on Microsoft.AspNetCore.OpenApi already ships beside it. Transformers instead of processors, AOT export via MSBuild tricks, and a golden-master test suite. Part 8 of FastEndpoints — The Missing Chapters.
FastEndpoints.OData is ninety lines that bolt Microsoft's OData query engine onto a REPR endpoint - a sealed Configure(), a fake ParameterInfo, and an endpoint filter that fishes the response out of HttpContext.Items. Reading it is a masterclass in integrating with a framework through its narrowest seam. Part 7 of FastEndpoints — The Missing Chapters.
FastEndpoints.HealthChecks is the strangest package in the repository - it never references FastEndpoints. One extension method, an IStartupFilter, an always-healthy self check, and two probes Kubernetes understands. Part 6 of FastEndpoints — The Missing Chapters.
Mappers, validators, processors, even the Resolve<T>() you call in a handler - almost none of it goes through your DI container the way you assume. A static ServiceResolver with two caches sits behind everything, and reading it explains both the speed and the sharp edges. Part 5 of FastEndpoints — The Missing Chapters.
The Config object you lambda into UseFastEndpoints is a thin view over nine process-wide static option singletons - and its properties hide the most useful hooks in the library: endpoint filters, a global configurator, warm-up, serializer swaps and custom value parsers. Part 4 of FastEndpoints — The Missing Chapters.
FastEndpoints ships a CSRF middleware that is opt-in per endpoint, only inspects form posts, and refuses to start your app if you wired it up wrong. It earned a single clause in seventeen parts - here is the whole story. Part 3 of FastEndpoints — The Missing Chapters.
The Send facade is a struct, its methods return a fake Void, and every sender secretly marks the response started before writing a byte. A tour of the response surface the deep dive skipped - files, ranges, redirects, interceptors and all. Part 2 of FastEndpoints — The Missing Chapters.
Seventeen parts of reading FastEndpoints and the series never once mentioned mappers - the entity-translation layer half the endpoint base classes exist to serve. The Missing Chapters opens with the biggest gap: where mappers live, how they are found, and why they are secretly singletons. Part 1 of FastEndpoints — The Missing Chapters.
The retrospective - configuration stays mutable, ordering stays emergent, one method absorbs every concern, and the only outside contributor correctly chose to duplicate sixteen lines rather than refactor.
Every downstream response is buffered into a UTF-16 string and re-encoded on the way out, so binary bodies corrupt silently behind a plausible status code and a recomputed Content-Length.
Twenty-two registrations, zero scoped, zero transient - a lifetime decision that buys a genuinely fast request path and enables exactly three bugs, all of them the same mistake.
services.BuildServiceProvider() inside ConfigureServices - what it actually costs, why it does not leak here, and how a zero-parameter extension method signature forced it.
The README and the sample both configure an auth claims alias map, the configuration class has no such property, and the binder's ignore-unknown-keys behaviour is what makes the omission silent.
Three components decide independently whether a route needs authentication, only one of them consults auth.enabled - and the combination that turns a public route into a 403.
A validated POST is parsed, re-serialised and parsed again on its way to a schema compiled fresh per request - and when it fails validation the caller gets HTTP 200.
Two mini-languages share one parser that runs both resolvers unconditionally and strips the first and last character from every token - and it is correct only by coincidence.
Two notions of module identity, a silent continue on a missing file - and a live bug the unreachable code was hiding.
Forty lines build every upstream path Ntrada can express, and thirty more build the downstream URL - where named segments substitute, one key appends, and one config flag runs backwards.
Ntrada's request pipeline is a gate and a dictionary lookup - and four extension hooks around it, one of which lost the thing it existed to see when a disposal bug was fixed.
Ntrada writes no middleware - it compiles YAML into ASP.NET Core endpoints and lets the framework's matcher do the work. Then you try to declare a PATCH route.
A 2018 API gateway promises that routing, auth, validation and messaging need no code at all - this series reads the source that makes the promise true, and the places where it is not.
