finds.dev — Ado's edition
5 picks this week.
A light-weight REST API development framework for ASP.NET 8 and newer.
FastEndpoints organizes ASP.NET APIs around the Request/Endpoint/Response pattern: one class per endpoint, validated request DTO, typed response, and pre/post processors hanging off the side. It sits on top of minimal APIs rather than MVC, so you skip the reflection-heavy filter pipeline and get startup performance close to raw lambdas — but with actual structure.
Source generators handle endpoint discovery and DI registration at compile time, which means misconfigured assemblies fail fast and startup time stays low regardless of endpoint count. The built-in testing factory and typed HTTP client extensions genuinely cut down integration test boilerplate compared to rolling your own WebApplicationFactory setup with manual HttpClient serialization.
The optional packages are worth knowing about: job queues, idempotency middleware, gRPC-based remote event bus, and OpenAPI generation are all separate NuGet packages. You can ignore every one of them and have a clean, minimal setup — or pull them in incrementally. The gRPC event bus layer is the least polished piece; the at-least-once delivery contract is real but the documentation around implementing your own storage provider is thin enough that you'll be reading source code.
The biggest gotcha is the God object base class. Every endpoint inherits Send*, AddError(), ValidationFailed, HttpContext, and a pile of other members as instance state. This is convenient and also the reason isolated unit tests are harder than the docs suggest — writing tests against a handler that expects a live HttpContext is friction you feel quickly. If your team is serious about unit-testing handlers, budget time for that discovery up front rather than mid-sprint.
Full Modular Monolith application with Domain-Driven Design approach.
This is the reference app to read when you want to see modular monolith + DDD tactical patterns implemented at a non-trivial scale, not explained in a blog post. Four modules (Meetings, Administration, Payments, UserAccess), each with its own Autofac container and PostgreSQL schema, communicating only through an in-memory integration event bus. The code reflects the architecture diagrams, which is rarer than it should be.
The decorator pipeline for cross-cutting concerns is the part most teams can steal directly: validation, logging, and unit-of-work are applied as decorators around command/query handlers rather than baked into a framework. The 17 Architecture Decision Records are genuinely useful — they document real debates like whether commands should return values, not just post-hoc justification for choices already made.
Testing is unusually thorough for a reference repo: domain unit tests against public API only, NetArchTest-enforced module boundary tests that run in CI, integration tests, and Stryker mutation testing. The multi-layer approach is worth studying even if you adopt none of the other patterns.
That said, be clear-eyed about what you're inheriting. The in-memory event bus means no multi-instance deployment without replacing a central piece of the design. IdentityServer 4 is archived and EOL, and the OAuth flow used is on the deprecation path in OAuth 2.1 — this is a real cost, not a minor upgrade. The repo last saw meaningful commits in mid-2024 and targets .NET 7/8 era dependencies. Treat it as a patterns reference, not a project template.
A reference .NET application implementing an eCommerce site
eShop is Microsoft's current flagship .NET reference application, rebuilt on .NET 9 and .NET Aspire. It covers Catalog, Basket, Ordering, Identity (Keycloak), and a MAUI mobile client, wired together with gRPC, RabbitMQ, Redis, and PostgreSQL. The Aspire orchestration is the most immediately useful part: the AppHost project replaces a fragile docker-compose setup and gives you service discovery, structured logs, and traces locally with minimal configuration.
The patterns in play are real, not toy versions: outbox for integration events in Catalog.API, explicit EF Core entity configurations (no convention-heavy magic), OIDC with Keycloak rather than a fake auth server. Playwright e2e tests and azd integration for Azure deployment are included, which at least gives you a working CI/CD reference to adapt.
The gaps are significant if you're evaluating this as a template for production code. There are essentially no unit tests for business logic — the emphasis is architectural demonstration, and that's fine, but budget for building out the test layer from scratch. The MAUI client has leftover mock services and fake data that appear to be scaffolding from an earlier version; reading that code to understand what's actually implemented versus stubbed is genuinely confusing.
The order flow uses integration event choreography across services, which works fine for the demo but has well-known failure modes at scale with no saga or process manager in sight. The repo doesn't acknowledge where this pattern starts breaking down, which matters if you're using this to inform a production architecture. Non-Azure deployment also requires meaningful extra work despite the microservices-should-be-portable framing.
.NET Transactional Document DB and Event Store on PostgreSQL
Marten gives you a document database and ACID event store backed by PostgreSQL's JSONB columns, addressable via a C# LINQ API. The pitch is that you get document and event sourcing patterns without adding a separate database engine to your infrastructure. The active JasperFx maintenance and commercial support backstop make this a reasonable production bet, not just an interesting experiment.
The event sourcing support is the standout feature. Append-log primitives are table stakes; Marten also ships an async daemon for rebuilding projections offline, multi-stream projections that aggregate across aggregate roots, snapshotting, archiving of old events, and subscription hooks. Schema management is automatic and migration-aware — Marten diffs expected schema against live DB and patches it, which is a genuine operational quality-of-life improvement over managing migration scripts manually.
Test infrastructure is well-designed: multiple base context types that isolate schema per test fixture and support parallel xUnit runs against a real database. This is the kind of thing that's easy to get wrong and annoying to retrofit, and Marten gets it right.
The edges to know before committing: the LINQ provider covers most common cases but complex group-by aggregations and some nested collection queries either silently evaluate client-side or throw — you'll discover these at test time, not compile time. The async daemon requires tuning (shard counts, batch sizes, error handling policies) that the docs describe without much production guidance on sensible defaults. Multi-tenancy's schema-per-tenant mode has cross-tenant query limitations that surface mid-project rather than during design. PLV8 is deprecated and the migration path for users who used the old patching API is documented minimally.
Blazor Component Library based on Material Design principles. Do more with Blazor, utilizing CSS and keeping JavaScript to a bare minimum.
MudBlazor is the closest thing Blazor has to a dominant UI component library: Material Design-based, JavaScript-minimal, and built entirely for the .NET developer who doesn't want to context-switch into CSS or TypeScript to build a form. The library ships with Roslyn analyzers that catch unknown parameters at compile time — a whole class of typo bugs that otherwise only fail at runtime in Blazor's parameter-binding model.
The docs site is built with MudBlazor itself and includes live interactive examples for every component, which is the correct way to document a component library. Test coverage is backed by bUnit and there's a benchmarks project that tracks render performance regressions — uncommon discipline for a UI library. The minimal-JS approach is genuine: most interaction goes through Blazor's rendering pipeline in C# rather than a JavaScript component wrapper.
The constraints are worth knowing before you start. Static Server-Side Rendering is explicitly not supported, and with .NET 8/9 pushing SSR as the default render mode for new Blazor apps, this is a meaningful architectural constraint rather than an edge case. Theming is done via C# MudTheme objects, not CSS custom properties, which means design token workflows and Figma handoffs don't map cleanly — you're working in the MudBlazor abstraction, not standard CSS.
The DataGrid has accumulated significant complexity and a history of breaking changes between minor releases; the migration guides are non-trivial. The library is also still on Material Design 2 aesthetics with no public commitment to MD3, so the visual style is already diverging from current Material guidance. For an internal tool or admin dashboard, none of this matters much. For a public-facing product with a design team, the theming limitations will surface quickly.