Over the past few weeks I’ve been digging into Minimal APIs, a feature of ASP.NET 6.0 that provides a new way to build HTTP services. You can find all my posts on Minimal APIs here.
The response to Minimal APIs has been fairly mixed. For some this is a fresh new approach to building APIs without all the ceremony of MVC. For others, the examples may appear like demo-ware that could never be considered for “real world” applications.
So why is there so much hype about Minimal APIs? In this post I try to explain why you may want to consider using them and attempt to address some of the concerns I’ve seen raised on Twitter.
More choice is a good thing
Minimal APIs are an alternative way of building HTTP services. They do not replace the MVC framework that you know, and possibly love. MVC is a comprehensive framework that offers many great features out-of-the-box.
However, if you are looking for greater control over how you build your APIs but want something a bit higher level than ASP.NET middleware, then Minimal APIs may be a good fit. It is just another option (just like Carter) which can only be a good thing!
I don’t agree with the sentiment that Microsoft are making things more confusing by introducing an alternative approach. Choose what works for your needs, in the same way you hopefully do with any technology.
A lower barrier to entry
With the latest preview, the minimum code required to launch a “Hello World” API is as follows:
var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();
app.MapGet("/", () => "Hello World!");
app.Run();
As a seasoned .NET developer it’s easy to look at this and scoff - after all, no API is ever that simple!
However, as someone who is new to ASP.NET, this single file application is easy to understand. I may have never written C# before but can probably figure out (with a little help from code-completion) how to extend the example. A good developer experience is one that offers maximum value with as little effort and upfront knowledge as possible.
If this is what we need to increase the adoption of and interest in .NET, then I’m all in. Yes this may have been inspired by other modern web frameworks but why is that a problem? Would you rather be using web forms?
Minimal != Simple
I believe much of the scepticism has come from the name Minimal APIs; and the idea that any “Hello World” application that doesn’t do anything useful could be classed as Minimal. They could have called it “Slim”, “Lightweight”, “Raw” etc. and still have received the same reaction.
Minimal simply means that it contains the minimum set of components needed to build HTTP APIs, such as routing, model/parameter binding and serialization. It doesn’t mean that the application you build will be simple or not require good design.
Another concern is that promoting single file examples will encourage developers to build poorly structured applications. I’ve seen my fair share of grotesque MVC applications (controller constructor soup anyone?) to know building in a design pattern will not be your saviour. We shouldn’t need Microsoft to educate us that a 3000 line Program.cs file is a bad idea.
I find that one of the biggest advantages to Minimal APIs is that they make it easier to build APIs in an opinionated way. After many years building HTTP services, I have a preferred approach. With MVC I would replace the built-in validation with Fluent Validation and my controllers were little more than a dispatch call to Mediatr. With Minimal APIs I get even more control. Of course if MVC offers everything you need, then use that.
Performance is a benefit but not the benefit
Minimal APIs are faster than MVC but this is probably not a reason to go back and change all of your MVC applications, since MVC is also highly performant, especially with .NET 6.0.
In my very unscientific benchmark I achieved around 2k req/sec more with Minimal APIs than the 24k req/sec I achieved with MVC. The official benchmarks may show bigger gains than this but I would evaluate carefully whether you would benefit from such improvements. If load testing isn’t part of usual development process, you probably have your answer.
With all that said, I do like to limit the abstractions I have in place. If I could build a HTTP service with just middleware then I would, providing the development effort didn’t outweigh the performance benefit.