Best .NET frameworks for vertical slice APIs

Combined ranking

1. 1
   FastEndpointsGrade ↗Visit ↗—14 pts

   Claude #1Gemini #1Grok #2

   Purpose-built for the REPR (Request-Endpoint-Response) pattern, which maps almost one-to-one onto vertical slices — each endpoint is a self-contained class colocating request, validation (FluentValidation baked in), handler, and response, so a feature lives in one folder with no cross-cutting controller sprawl. Near-zero boilerplate, strong source-generated performance close to raw Minimal APIs, first-class model binding, built-in versioning, and good testing story. Best default for a team that wants VSA conventions enforced without hand-rolling them.

   + model takes & fixes− hide details

   Claude Purpose-built for the REPR (Request-Endpoint-Response) pattern, which maps almost one-to-one onto vertical slices — each endpoint is a self-contained class colocating request, validation (FluentValidation baked in), handler, and response, so a feature lives in one folder with no cross-cutting controller sprawl. Near-zero boilerplate, strong source-generated performance close to raw Minimal APIs, first-class model binding, built-in versioning, and good testing story. Best default for a team that wants VSA conventions enforced without hand-rolling them.

   Gemini Purpose-built for the REPR (Request-Endpoint-Response) pattern and Vertical Slice Architecture; encapsulates request, response, validation (FluentValidation), and logic into a cohesive single-class slice per endpoint with zero mediator overhead, excellent integration testing fixtures, and minimal API performance.

   Grok REPR (one class per endpoint) maps 1:1 onto feature folders; FluentValidation, OpenAPI, processors, versioning, and typed test helpers are built in; latency tracks Minimal APIs on .NET 10. Near-tie with #3 for HTTP-only teams that want enforced structure without inventing conventions.

   Where it falls short

   per Claude Opinionated class-per-endpoint structure and its own abstractions mean you're buying into a framework idiom; teams wanting to stay on stock ASP.NET primitives or needing heavy MVC-style controller features will chafe.

   per Gemini Not for teams committed to multi-layered hexagonal/clean architecture with strictly decoupled, protocol-agnostic domain handlers, or enterprise environments mandating zero third-party dependencies.

   per Grok Third-party HTTP stack with a public 2026 funding/bugfix-mode warning — not for teams that cannot accept community-maintained infrastructure risk.

2. 2
   WolverineGrade ↗Visit ↗—12 pts

   Claude #2Gemini #3Grok #1

   Purpose-built for vertical-slice APIs: the HTTP method is the handler (no controller → mediator → handler hop), convention discovery finds slices without custom wiring, compound handlers keep load/validate/act in one slice, and the same pipeline covers in-process commands plus a transactional outbox if the slice later publishes. Assumption that shaped the rank: the typical practitioner is shipping feature-rich APIs that will grow past CRUD, not a three-endpoint microservice.

   + model takes & fixes− hide details

   Grok Purpose-built for vertical-slice APIs: the HTTP method is the handler (no controller → mediator → handler hop), convention discovery finds slices without custom wiring, compound handlers keep load/validate/act in one slice, and the same pipeline covers in-process commands plus a transactional outbox if the slice later publishes. Assumption that shaped the rank: the typical practitioner is shipping feature-rich APIs that will grow past CRUD, not a three-endpoint microservice.

   Claude JasperFx's mediator-plus-messaging library collapses the handler/dispatch layer that VSA needs — convention-based handlers with no interface ceremony, and it doubles as a real transactional messaging/outbox and durable-inbox system (pairs natively with Marten for event sourcing). Its HTTP endpoints package lets a slice's handler be the endpoint, and compile-time codegen keeps runtime overhead low. Strongest pick when slices need to emit commands/events, not just handle HTTP.

   Gemini Uniquely excels for vertical slices in complex, event-driven, or transactional domains; uses source generation to compile HTTP endpoints and messaging handlers into zero-allocation execution pipelines, cleanly uniting HTTP APIs with message buses and transactional outbox patterns in the same slice.

   Where it falls short

   per Claude The convention-magic and codegen make debugging and onboarding harder; overkill if you only need request/response HTTP with no async messaging, and it pulls you toward the wider JasperFx (Marten) ecosystem.

   per Gemini Has a steep conceptual learning curve and unconventional runtime compilation model; significant overkill for straightforward synchronous CRUD Web APIs.

   per Grok Steep idioms and JasperFx/Critter Stack gravity — not for teams that only want a thin HTTP layer and refuse a messaging-shaped framework.

3. 3
   ASP.NET CoreGrade ↗Visit ↗—10 pts

   Claude #3Gemini #2Grok #3

   Near-tie with FastEndpoints; native first-party platform capability offering maximum throughput, zero external dependencies, seamless Native AOT compilation, and native RouteGroupBuilder support for grouping feature-folder endpoints directly in the runtime.

   + model takes & fixes− hide details

   Gemini Near-tie with FastEndpoints; native first-party platform capability offering maximum throughput, zero external dependencies, seamless Native AOT compilation, and native RouteGroupBuilder support for grouping feature-folder endpoints directly in the runtime.

   Claude The framework-native baseline — endpoint route groups, filters, and typed results give you enough to organize features as slices with zero third-party dependencies, full Microsoft support, and the best long-term stability and AOT/perf trajectory. With a light convention (a folder per feature + an endpoint-registration extension) it delivers honest VSA for teams that value owning their own structure.

   Grok First-party, zero extra license or runtime, Native AOT and OpenAPI are native, and .NET 10 added built-in validation — production VSA in 2026 is often just feature folders + MapGroup + a hand-rolled handler with no second framework. Wins when lock-in, hiring familiarity, and platform alignment beat opinionated structure.

   Where it falls short

   per Claude Provides no VSA opinion out of the box — validation, handler dispatch, and slice conventions are all DIY, so large codebases drift without team discipline or a helper library layered on top.

   per Gemini Lacks opinionated structural conventions out of the box, forcing teams to manually invent and enforce endpoint discovery, validation pipelines, and slice isolation patterns without compiler guidance.

   per Grok No slice conventions — not for multi-dev APIs that will rot into Program.cs/lambda sprawl without team discipline.

4. 4
   CarterGrade ↗Visit ↗—6 pts

   Claude #4Gemini #4Grok #4

   A thin, well-liked module layer over Minimal APIs that groups related endpoints into ICarterModule classes — a natural seam for one module per slice — while adding auto-discovery, FluentValidation integration, and content negotiation without hiding the underlying ASP.NET primitives. Low-lock-in middle ground between raw Minimal APIs and a full framework.

   + model takes & fixes− hide details

   Claude A thin, well-liked module layer over Minimal APIs that groups related endpoints into ICarterModule classes — a natural seam for one module per slice — while adding auto-discovery, FluentValidation integration, and content negotiation without hiding the underlying ASP.NET primitives. Low-lock-in middle ground between raw Minimal APIs and a full framework.

   Gemini The simplest low-ceremony organizer for structuring ASP.NET Core Minimal APIs into vertical slices via ICarterModule; delivers automatic endpoint registration while staying completely aligned with native framework primitives and zero performance overhead.

   Grok Thinnest useful module layer over Minimal APIs (ICarterModule per feature area, auto DI, FluentValidation hooks) so slices group without FastEndpoints/Wolverine opinions or a mediator.

   Where it falls short

   per Claude Deliberately minimal — it organizes routing but gives you no handler/mediation, so you still assemble the rest of the slice yourself; less momentum and feature depth than FastEndpoints.

   per Gemini Extremely thin scope; it only handles module discovery and registration, providing no built-in conventions for request/response typing, slice-level pipeline behaviors, or input validation.

   per Grok Small community and little beyond routing modules — not for teams that need processors, outbox, REPR testing, or a batteries-included slice runtime.

5. 5
   MediatRGrade ↗Visit ↗—1 pts

   Claude #5Gemini —Grok —

   Still the most widely understood way to express a slice as a IRequest/handler pair with pipeline behaviors for validation, logging, and transactions, paired with Minimal APIs or controllers as the transport. Mature, battle-tested, huge body of VSA examples built on it.

   + model takes & fixes− hide details

   Claude Still the most widely understood way to express a slice as a IRequest/handler pair with pipeline behaviors for validation, logging, and transactions, paired with Minimal APIs or controllers as the transport. Mature, battle-tested, huge body of VSA examples built on it.

   Where it falls short

   per Claude Went to a paid commercial license (Lulu/LamarCode) in its recent versions, changing the calculus for new projects; it's only in-process mediation, adds an indirection layer some now consider unnecessary, and does nothing for the HTTP edge itself.

Just missed the top 5

By model

Common questions

Tracked by ModelsAgree · rank 1 = 5 pts … rank 5 = 1 pt · re-polled on demand