DEV Community: Anaya Upadhyay

Minimal API vs Controllers in ASP.NET Core: When Each One Actually Wins

Anaya Upadhyay — Fri, 12 Jun 2026 06:15:00 +0000

Somewhere around .NET 6, the Minimal API question stopped being academic. Teams actually started shipping with it. And then some of those teams quietly started adding Controllers back six months later.

Both choices can be correct. The problem is that the wrong framing "which one is simpler?" or "which one is more modern?" lands you in the wrong answer. Here is the framing that works.

The real question

Both Minimal API and Controllers ship working APIs. What they optimize for is completely different, and ignoring that difference is how you end up refactoring.

Start with three questions:

How complex is your routing logic?
A handful of endpoints vs. a full domain model with dozens of grouped resources. That gap matters.

Do you need the full action filter pipeline?
Controller action filters and DI-bound per-action behavior make unit testing dramatically easier at scale. Minimal API has endpoint filters, they work, but they are not the same abstraction.

Who else touches this codebase?
Controllers have 15 years of conventions. A developer who has never seen your project knows where to look. Minimal API is learnable fast, but it is not pre-loaded.

When Minimal API wins

Microservices with a narrow surface area

One service. A handful of well-defined endpoints. You do not need to carry the full MVC stack for a payment webhook receiver or an internal reporting service. MapGet, MapPost, done.

Internal tooling and prototypes

You want working code in minutes. Controllers impose ceremony that has no return on a one-team service nobody else integrates with. The shorter the expected lifespan, the higher the ceremony cost.

HTTP-native patterns

Webhooks, health checks, simple CRUD. Request in, response out. The Minimal API pipeline maps directly to those problems. No inheritance, no attributes, no discovery conventions.

Small teams that own the full stack

When the team is small and the scope is bounded, conventions are mostly overhead. Minimal API gives that team agency over their own structure without fighting a framework.

What a clean Minimal API endpoint looks like

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

// GET /products/{id}
app.MapGet("/products/{id}",
    async (int id, IProductRepository repo) =>
{
    var product = await repo.GetByIdAsync(id);
    return product is null
        ? Results.NotFound()
        : Results.Ok(product);
});

app.Run();

The whole thing fits. DI works. IProductRepository is resolved from the container automatically. Results helpers cover the common response patterns without IActionResult boilerplate.

When Controllers win

Large domain with many grouped resources

ProductsController, OrdersController, UsersController. Controllers namespace your API implicitly and make routing intentions explicit without attribute gymnastics. At 40+ endpoints the ergonomics flip decisively.

Action filters are doing real work

Audit logging, model validation attributes, custom authorization policies scoped per action. The filter pipeline on Controllers is composable in ways that Minimal API endpoint filters currently are not. If your cross-cutting concerns are complex, go where they fit cleanly.

Multiple developers sharing the codebase

This one is underrated. Controllers have 15 years of conventions behind them. A new developer knows where to look without asking anyone. That knowledge is worth something, especially as the team grows.

Versioned APIs with complex binding

Route groups help in Minimal API, but versioned controllers with [ApiVersion] and strongly-typed model binding still carry less ceremony in practice. If you are versioning three major API versions in production, Controllers are the path of least resistance.

The same endpoint as a Controller

[ApiController]
[Route("api/[controller]")]
public class ProductsController : ControllerBase
{
    private readonly IProductRepository _repo;

    public ProductsController(IProductRepository repo)
        => _repo = repo;

    // GET api/products/{id}
    [HttpGet("{id}")]
    public async Task<IActionResult> GetById(int id)
    {
        var product = await _repo.GetByIdAsync(id);
        return product is null
            ? NotFound()
            : Ok(product);
    }
}

More structure. More surface area. Worth it when that structure is carrying load.

The side-by-side

Dimension	Minimal API	Controllers
Boilerplate	Minimal	Moderate
Testability	Good with DI	Excellent
Action filters	Endpoint filters only	Full filter pipeline
Routing	Lambda, explicit	Attribute + convention
Team ramp-up	Fast for new .NET devs	Familiar to most devs
Scale target	Micro to mid	Mid to large domain
Swagger / OAS	Full support	Full support

Neither row is a clear winner on every dimension. That is the point.

The hybrid pattern. You do not always have to pick

This is the one that most people miss. You can use both in one solution:

// Program.cs
var app = builder.Build();

// Minimal API: health + lightweight probes
app.MapGet("/health", () => Results.Ok());
app.MapGet("/version", () => AppInfo.Version);

// Controllers: complex domain resources
app.MapControllers();

app.Run();

MapControllers() and MapGet() compose cleanly. Route groups and controller routing do not conflict. Use Minimal API for the surface area where it fits, Controllers where the domain needs structure.

This is not a workaround. It is a supported, intended usage pattern.

The decision checklist

Save this for the next project kickoff:

New microservice or internal tool → Minimal API
Existing codebase already on Controllers → Controllers
Need action filter pipeline → Controllers
Prototyping or validating an idea → Minimal API
Large domain, many grouped routes → Controllers
Mixed concerns in one solution → Hybrid

What actually goes wrong

The most common failure mode is not choosing the wrong approach. It is choosing one approach and never questioning it as the project grows. A project that starts as a three-endpoint Minimal API and quietly becomes a 60-endpoint domain model has a debt problem.

Pay attention to the signals:

Duplicated per-endpoint middleware logic → Controllers
Handler functions growing past 30 lines → consider Controllers
Difficulty testing endpoints in isolation → Controllers
Ceremony cost outweighing value → reconsider Minimal API The framework does not enforce a migration path. You have to notice it yourself.

The full carousel version of this breakdown (with code examples for each scenario) is on Instagram at @thesharpfuture.

Log Aggregation in .NET 8: Seq vs ELK vs Loki

Anaya Upadhyay — Tue, 26 May 2026 09:15:00 +0000

I have seen the same setup at more companies than I can count: every service writing logs to stdout, a few rotating files scattered across VMs, maybe one service sending to Application Insights, and nobody quite sure where the logs from the background jobs go.

It works fine until something breaks in production. Then you have an error, four services, and zero way to trace a single request across any of them.

That is the problem log aggregation solves. This article covers what it actually means in a .NET 8 stack, how to set it up with Serilog, and how to pick the right aggregator for where your team is right now.

What log aggregation actually means

The idea is simple: every service in your system writes structured log events to a central store, and you query that store instead of grepping files.

The pipeline has three parts:

Your app - calls ILogger<T> with structured message templates
A sink - Serilog serializes and ships the event to a destination
An aggregator - receives, indexes, and stores the events so you can query them by any property

The key word is structured. If your log messages are plain strings, you have traded one grep problem for another. The entire value of aggregation comes from being able to filter on OrderId, CorrelationId, CustomerId, or any other property you attached to the event.

Setting up Serilog with multiple sinks

Sinks are composable. You can write to Seq locally, Elasticsearch in production, and a rolling file as a fallback, all from the same configuration.

// Program.cs
Log.Logger = new LoggerConfiguration()
    .Enrich.WithCorrelationId()
    .MinimumLevel.Override("Microsoft", LogEventLevel.Warning)
    .MinimumLevel.Override("System", LogEventLevel.Warning)
    .WriteTo.Seq("http://localhost:5341")
    .WriteTo.Elasticsearch(opts =>
    {
        opts.IndexFormat = "logs-{0:yyyy.MM}";
        opts.AutoRegisterTemplate = true;
    })
    .WriteTo.File("logs/app-.log", rollingInterval: RollingInterval.Day)
    .CreateLogger();

builder.Host.UseSerilog();

A few things worth noting here. The MinimumLevel.Override calls are important in production. Without them, Microsoft framework internals log at Debug and they will flood your aggregator with noise that buries your actual signals. Set them to Warning in production environments.

The Enrich.WithCorrelationId() call requires the Serilog.Enrichers.CorrelationId package. Pair it with a middleware that sets BeginScope on every request and every log line inside that request will carry the same correlation ID. Without it, log aggregation gives you a better filing cabinet but not a better answer.

Seq: start here

If your team is not running a local aggregator today, start with Seq. It is free for individual use, has first-class support for structured .NET logs, and takes about two minutes to set up.

docker run --rm -e ACCEPT_EULA=Y -p 5341:5341 -p 80:80 datalust/seq:latest

Then in appsettings.Development.json:

"Serilog": {
  "WriteTo": [{
    "Name": "Seq",
    "Args": { "serverUrl": "http://localhost:5341" }
  }]
}

Open http://localhost and you will see every structured event your application emits. Filter by @Level = 'Error', or OrderId = '123', or CorrelationId = 'abc' - all of it works immediately because the properties are indexed, not buried inside a string.

The query experience alone is worth it for local development. You stop reading raw console output and start asking questions.

Picking a production aggregator

Here is a direct comparison of the three options most .NET teams evaluate.

Seq

Good for teams up to maybe 20 engineers with moderate log volume. The single-node architecture is a real ceiling but it is not a problem until it is a problem. Reasonably priced for small teams and the operational overhead is low. If you are a startup or a small product team, Seq in production is a completely legitimate choice.

ELK Stack (Elasticsearch, Logstash, Kibana)

The right choice when you have high volume, need full-text search across log content, or have an ops team that can own the infrastructure. Kibana dashboards are genuinely good for sharing observability across engineering and operations. The tradeoff is real though: you are running three services, Elasticsearch is resource-hungry, and the licensing situation has changed a few times in recent years - worth reviewing before you commit. Not a good first production choice for a small team.

Grafana Loki

Loki takes a different approach. Instead of indexing the full content of every log line, it indexes labels only. This makes it significantly cheaper at scale. The tradeoff is that you cannot do full-text search across log content by default - you query by labels and then filter within results.

If your team is already running Grafana and Prometheus, Loki is the natural addition. It integrates tightly with both and keeps your observability stack in one place. On Kubernetes it scales well horizontally. The LogQL query language takes getting used to, but it is not complex.

The three mistakes that break aggregation in production

String concatenation in message templates. The moment you write _logger.LogInformation("Order " + id + " placed"), the structured property is gone. The aggregator receives a plain string. You cannot filter on OrderId in Seq or Kibana because it does not exist as a property. Always use message templates: _logger.LogInformation("Order {OrderId} placed", id).

Console.WriteLine anywhere in your codebase. It bypasses every sink. It is unstructured, and in a containerised environment it is lost on restart. Any Console.WriteLine in application code should be replaced with ILogger. This includes library code you own.

No minimum level override per environment. Framework-level components log a lot at Debug. In production, shipping those events to your aggregator wastes storage and makes real errors harder to find. A MinimumLevel.Override for Microsoft.* and System.* set to Warning is one configuration line that keeps your signal-to-noise ratio sane.

Before you configure anything

The aggregator is the last decision, not the first.

Get structured message templates right across your codebase. Set up a correlation ID scope in middleware so every log line in a request shares an ID. Pick the minimum level that makes sense for each environment.

Once those are in place, the aggregator almost does not matter. Seq, ELK, Loki - they are all just different query UIs sitting on top of the structured events your app already emits correctly.

This article is part of Logging in .NET - Series 2. The full carousel version with sink configuration code and a setup checklist is on Instagram at @thesharpfuture.