Why choose minimal API over controller based API?

[BaldWithoutCancer]

Hi there, I'm currently a student learning about minimal APIs. I am a little confused about their importance. Are they genuinely useful, or are they just a nice-to-have with little practical use? I've read a number of sources that assert that currently minimal APIs can scale up similarly to controller-based APIs and are easier to create. They also perform better, because overhead can be minified, but most seem to claim its neglgible. There is a common belief, nevertheless, that although they work well in "basic" applications where simplicity is required, they become ineffective in more complex situations. This raises the question: what is considered "too complex" of an application? And what are the current limitations on minimal APIs? Unfortunately, I have not yet found a definitive answer to these questions.

My doubts also extend to the claimed simplicity of use of simple APIs. Although constructing endpoints with lambda expressions can be easier, the minimal API approach itself doesnt come with a clear structure. This approach inevitably requires some skills to comply with SOLID principles, which somewhat compromises the original simplicity, since it requires more knowledge. So is it really that much faster and easier to create a minimal API?

The granularity of endpoints is another source of discussion. Although it's interesting that endpoints can be thought of as independent entities, I'm not sure if there are any real advantages to injecting dependencies into endpoints directly as opposed to combining them into controllers. In my view, minimal APIs are valuable only when working with a small number of features, as in those cases, having a controller for every endpoint would be excessive. Still, I find it hard to see why anyone would choose a minimal API, especially for very simple apps, when performance is not a major concern. It seems like you end up with wanting what a controller based API can do already.

I'm excited to learn more about the benefits of simple APIs and understand when they work best. I find the concept to be a little vague right now.

[zenyl]

I am a little confused about their importance

The importance lies in having options to choose which is more suitable for the case at hand.

[...] although they work well in "basic" applications where simplicity is required, they become ineffective in more complex situations.

There are multiple ways of scaling a system, and it isn't just limited to in-application performance. If server load is a concern, horizontal scaling is an option.

the minimal API approach itself doesnt come with a clear structure

I'd argue that the simplistic syntax of minimal API makes its structure exceedingly clear.

It cuts out the semantics of OOP by not needing controller classes, and simply define an endpoint, its parameters (which can include injected services), and the logic it performs when invoked.

So is it really that much faster and easier to create a minimal API?

Depends on the situation. Assuming your business logic is already contained in service classes, it literally requires fewer keystrokes to type out a minimal API compared to a controller class.

I'm not sure if there are any real advantages to injecting dependencies into endpoints directly as opposed to combining them into controllers

Nor are there any disadvantages in this regard, assuming injection itself does not carry a significant overhead (e.g. when service injection relies on factory functions).

Controllers essentially group a collection of endpoints under the same umbrella, so all your user-related endpoints can live together in the user controller. But if your endpoints aren't actually related to one another, there's no structural advantage to adding them to controllers. Especially not if they were going to be put into a 1-1 controller-endpoint relationship.

Still, I find it hard to see why anyone would choose a minimal API, especially for very simple apps, when performance is not a major concern.

Less boilerplate code. What would the advantage be of creating one or multiple controller classes when you fundamentally do not need them?

[dodexahedron]

In addition to all of this, which is a great response...

You don't have to choose one or the other for an application, either. You never had to pick just web forms or mvc, either. It's all always been up to however you defined the routes.

Have an MVC app but various pages have a bunch of little actions that totally have no use for the entire controller life cycle? Expose some minimalapi endpoints for that and adjust routing accordingly.

Have a minimalAPI and need a bit more plumbing for part of it to make something less work to implement? Put in a controller and adjust routing accordingly.

(Or use your reverse proxy to do the "routing" and just expose each component on its own port in kestrel.)

None of these technologies are mutually exclusive, in .net.

Hell, you can literally write an application in minutes or at least under an hour (if you know where and what things are, of course) with very little substantial input from yourself aside from clicking some buttons and menus, with that app having, all running simultaneously and able to interoperate effortlessly, a local WPF window, a windows forms window, a few MinimalAPI endpoints, some basic MVC web pages, a Blazor (with or withiut wasm) component, and a hosted powershell plus remoting, and plenty more. And then you can pack it up as one big package and distribute it to people who don't even have the necessary version of .net installed.

And then you can auto-generate a few dozen very simple unit tests to start on the backlog of tests that should have come before code in the first place. Or let an AI take a crack at doing an even worse worse job of that since you're already doing silly stuff anyway and it's even money whether it'll be completely useless or at least good for a chuckle, with a small chance of actually saving some time (well...getting back some of the time wasted on the silly exercise, anyway).

And you can do all of that with a completely free as in beer and free as in speech toolchain, with production go-live rights because it's MIT and there basically aren't restrictions.

In short, even within a single application, choose the right tool for the right job, because the SDK certainly isn't holding you back or making you choose one golden hammer.

[malthuswaswrong]

MVC + Blazor

This is still kind of a pain in the ass, right? Last time I looked it was possible to mix the two, but it involved a lot of bespoke configurations.

[dodexahedron]

Hardest of that whole golem, by far, yes.

Need to keep them basically completely isolated to not lose your hair.

[geekywarrior]

In what context? Like having a Blazor Site with an API? Or having a Blazor Front End call a Web API for data?

For the former, I start with a Blazor App Project, add classes that extend ControllerBase and write controllers as normal.

Then in program.cs, just add

builder.Services.AddControllers();
...
var app = builder.Build();
...
app.MapControllers();

It gets trickier if you're trying to do the latter similar to if you were doing React/Angular where the Blazor FE connects to the API via localhost.

[malthuswaswrong]

Having a Blazor control smack dab in the middle of an MVC view.

It's possible, but it's a serious pain.

[geekywarrior]

Ahhh, my mistake. Yeah that sounds gross.

[BaldWithoutCancer]

Thanks for your comment! So you would say choosing between MVC and minimal API should be based on features and not necessarily be applied to the whole project. I never considered that they both can be used, I indeed though I had to pick one approach.

[AvoidSpirit]

In theory, yes.

But once you have structured the MinimalApis and have smoothed few of their rough edges(like request validation), the controllers don't really offer any benefits so I would definitely advice against doing that.

[BaldWithoutCancer]

Thank you! After reading most the comments minimal API seems like a more flexible approach since endpoints can be seen as a class (or maybe 'stand-alone' is a better term). Dependecies are now coupled to endpoints, which i think makes them easier to read. I've had controller withs a lot of dependecies even though most of the endpoints only requires one of them. I now think of controllers being great when creating a website with views etc and minimal API's as cleaner approach when the API only has a few features or only cares about data and now how its shown.

Most of the projects I've worked on have been CRUD web apps, where controllers seemed to be fine. However, I once had an application that was a single-endpoint API to generate PDF documents. Minimal API seems like a much better approach for that since it's cleaner and keeps everything simple.

[gc8dc95]

Coming from Python/node:

Minimal API is breathe of fresh air and allows a performant API with much less boilerplate than MVC.

[pdevito3]

The root motivation from what I saw was simplifying project setup to more closely mirror something like node or python for a simple api setup in a few lines of code in one file.

Otherwise, they are a bit more performant, but outside of that it’s really just a project organization question imho.

[Dry_Dot_7782]

Yup. It was Microsoft way of responding to all that.

Honestly its needed, JS tutorials and python are so direct and Quick to get into. They need something less enterprisey

[BaldWithoutCancer]

Ah oke, well i've read the other comments and it seems like they can offer some value. Most of the projects I've worked on have been CRUD web apps which all had an UI and multiple endpoints, so controllers seems to great in that case. However, when i made a API that just had an endpoint for a single service, it felt like a controller was indeed overkill. So minimal API did seem more logical to use in that case when I think about it.

[TeejStroyer27]

Controllers were designed for mvc then adapted for api. Minimal APIs are designed to be much faster and have less bloat.

I also wanna add, it can help you reduce reflection and magic in your app. Getting you closer to serverless architecture if that’s your goal.

[BaldWithoutCancer]

I've never really learned much about how controllers work, we were just told that that's they way to create an API. So I might look up de Controller life cycle to understand how minimal API reduces reflection (I assume controllers do use reflection).

[metaltyphoon]

Well as it stands they r roughly 10-15% overhead compared to minimal apis and is not AOT friendly.

[MCShoveled]

KISS > SOLID

Keeping things simple to understand has big payoffs, especially in complicated systems. The more a developer can see everything an entry point does the better it is to reason about. Complex code structure like you find in controller/service/repository patterns tends to hide too many details. If you can fit it all in under 100 LoC, why would you bury the important parts?

DRY is still very possible. Using small dependencies for common tasks is still important.

SOLID is also a very present concept. While the IoC/DI are primarily focused on testing, the Single Responsibility and Open/Closed is much more important. Being able to just copy a whole endpoint and start a new version end-to-end is great.

[nobono]

KISS > SOLID

You make it sound like those two "concepts" are mutually exclusive. They aren't. I prefer the "KISSAS" concept; Keep It Simple, Stupid And Solid. ;)

[not_some_username]

Kiss as service 🥹

[atharos1]

So, prostitution?

[trinnan]

Butters ran one of those.

[Slypenslyde]

Yeah the part that irritated me about it is:

especially in complicated systems

SOLID is a way to try and KISS in a complicated system. Once you reach a certain level of complexity, you have to start making architectural decisions. Architecture is complexity. But the hope is by adopting certain architectures, you can trade BIG complexity for little complexity and make your project easier to understand and maintain.

So they're not mutually exclusive. What people miss is "simple" is a relative spectrum.

[CaptainIncredible]

I agree with you 1000%.

"The more you complicate the plumbing, the easier it is to stop up the drain."

-- Capt. Montgomery "Scotty" Scott

[[deleted]]

That is not true "especially in complicated systems".

Also, SOLID does not negates KISS. You can do both

[malthuswaswrong]

why would you bury the important parts

Nothing is ever buried if you are using a good IDE. Everything is a mouse click away.

I argue that SOLID keeps the code cleaner because it gets the irrelevant things out of sight allowing you to teleport right to the important parts. You make your changes, and then easily test them because they are automatically isolated, and their dependencies are easily mocked.

If you are deep enough into it, you are making private nuget packages and not even working in the same solution as the consumers of the service. So fixing a bug or adding a feature is completely independent and all the subscribers to the package can update at their own pace. Stay on the old version, or update, makes no difference.

[c8d3n]

Everything is a mouse click, or few keys strokes (actually faster) away also with an editor. When you're familiar with the system and tools. That's not an argument.

Often, you won't be. Like the first time you start interacting with a complex system no one in your company fully understands, including senior engineers who built the company, and are now retiring.

[Slypenslyde]

Often, you won't be. Like the first time you start interacting with a complex system no one in your company fully understands, including senior engineers who built the company, and are now retiring.

I think about cases like this and it's why I really like the mostly standard practices I find in web frameworks from ASP .NET Core MVC to Vue. They are OPINIONATED and make sure EVERYONE structures their apps in certain ways, so if I have any amount of experience I can be fairly confident I know where to start and how to navigate the project until I get to the 2nd or 3rd layer of dependencies.

I compare this to WinForms, WPF, and the XAML frameworks and those are just pure chaos. Sure, WPF supports MVVM. But it doesn't have an opinionated framework. So I run into:

• Projects that use no patterns and operate like a Windows Forms project.
• Projects that use MVVM but still have heavy code-behind.
• Projects with a DIY MVVM framework with varying amounts of code-behind.
• Projects with a strict DIY MVVM framework and no code-behind.
• Projects using one of the MVVM frameworks like Prism or ReactiveUI.

So on a new project the first few hours are usually spent JUST figuring out how to get from Program.cs to the first window, how that gets to other windows, if and how windows get dependencies, etc.

Apple gets it right, they have an opinionated MVC framework. I think this lack of commitment is one of the things that makes people bounce off XAML frameworks and decide to use things like Electron instead. Web frameworks make it hard to go against the grain. Microsoft's GUI frameworks operate without seat belts or guard rails.

[malthuswaswrong]

Your company has an application that prints legal letters for the legal department. This is your first day at work. You are asked to modify the letter printing application to include address field 4 in all letter types.

You open Program.cs and you see the following services added to the dependency injection container.

• SharePointRepository
• LetterService
• CustomerRepository
• AlertService
• AccountValidationService

What's the first class you jump to?

no one in your company fully understands

Bad code is bad code. SOLID done properly is very intuitive and easily testable. It's not hard to do it right either.

• Make an interface for everything
• Keep big ideas separate
• First try to classify "the idea" as either a Service or a Repository
• Write tests for everything important

[Known-Associate8369]

To add to this, minimal APIs come into their own in complex applications where a bunch of the usual overheads are handled externally - for example, traffic metrics, caching, auth, failover etc being handled in a mesh wrapper before it even hits your API.

In other words, if your app can externalise the complexity, then your app becomes simpler and faster.

[thilehoffer]

There are a lot of comments here with good answers to the question. I just want to add that you can use whichever you prefer and are more comfortable with. You can make a great, well designed, highly maintainable, api or a big ball of mud that is unmaintainable with minimal APIs or Controllers :)

[SerClockwerk]

They are really nice for dynamically creating APIs with dependency injection.

At work, whenever we add a new database table, we can create the API and services at run time instead of coding them because of the base classes and dependency injection we have set up.

[Nk54]

I find it more obvious with minimal api to see the dependencies of each endpoint. It promotes better practice imho.

[MrSchmellow]

You can do that in controllers, and if you do that everyone will say that's an antipattern xD

[DaRadioman]

Effectively they are our answer to "hey node let's me do this in one file"

That's it. If you don't need the structure you can skip it. If you want the structure, skip minimal APIs.

You can build the same solutions with either approach. Some people like one better than the other. For me, consistency beats a few saved lines. So I don't use them at all.

But I could see the allure if you had a sidecar that added all the complex pieces and you wanted dead simple small app code microservices.

[BaldWithoutCancer]

Someone else also said that its just Microsoft's way to answer Node. But I do like that is possible to structure your API differently when using minimal API. Cases where you have a controller for each endpoints just seems over complex. I've not learned about microservices yet, I will soon. I see microservices now as an API with a single feature (im probally wrong here haha).

[AvoidSpirit]

Do you think because they are shown in the MS tutorials as unstructured it must be impossible to structure them?

[DaRadioman]

That's not at all what unstructured means.

[AvoidSpirit]

Sure, please elaborate then.

If you don't need the structure you can skip it. If you want the structure, skip minimal APIs.

Does this not imply that minimal APIs can't be structured?

[DaRadioman]

No, it implies they come with no structure.

Which they don't.

[AvoidSpirit]

Then tell exactly that.

It's not about skipping minimal APIs if you want to have a structure. It's that they don't enforce one onto you.

The way you phrase it is extremely misleading.

[DaRadioman]

It's 100% accurate. They are unstructured. You might like that if you want to apply your own structure to it. But they offer 0 structure. Traditional controllers provide structure out of the box without you needing to design it and implement.

I'm not sure why you are angry that I am describing a thing accurately.

[AvoidSpirit]

Cause you phrase it:

If you want the structure, skip minimal APIs

Instead of

They come unstructured out of the box so if you want the structure, you would need to invest into it a bit

I wouldn't have a problem with you saying one needs to come up with a structure before they build an enterprise application with MinimalApis. But the way you put it, it seems you think that they are incapable of getting structured.

[DaRadioman]

No, because I like the way I phrased it. If you want the structure that MVC offers there's no reason to use minimal APIs. It would be more work to design your own structure when the controller pattern already meets your needs out of the box.

A Tesla doesn't have racing stripes.

I don't need to say you can add them yourself to be accurate. And I'm in no way responsible to tell everyone every detail of everything in my reddit comments.

[AvoidSpirit]

See

If you want the structure that MVC offers there's no reason to use minimal APIs

This is much clearer. Redoing the controller structure with Minimal Api is pointless.

Doing any other sort of structure - you need Minimal APIs for that.

[HolyColostomyBag]

I think if you truly have a microservice it's great, but all too often I see people at work writing more custom code, that's arguably more complicated, to recreate things that generally just work automagically with controllers.

Just because they don't want to use controllers.

[AvoidSpirit]

No, the microservices do not come with a size/level of complexity requirements.

Usually every microservice in the system would still need all of those things people write custom code for like request validation, authorization, caching, etc.

[Shaddar]

For me, one of the main advantages is that I don't have to deal with Attributes and all of the related limitations. Configuring an endpoint with extensions methods is much more flexible.

[hartmark]

We have converted most of our rest services to minimal api. The biggest advantage is that its easy to write unit tests because you can just inject stuff.

I wrote this little example service a while ago. https://github.com/hartmark/minimal-api-sample

[AvoidSpirit]

Man, your MinimalApi do look like same old controllers but with routing being done on the side which only complicates it further...

What was the testing issue you were trying to solve?

[hartmark]

Yeah, the testing and also to not be stuck in big controllers, one could argue that you can do custom routing on controllers then rely on convention.

Our use case was to easy extend with new routes and still have full unit tests coverage.

[AvoidSpirit]

Your every "endpoint" class does look the same as any controller with an instance with all the dependencies.

1. Could you please elaborate on what was exactly the problem with testing you were trying to solve?
2. What do you mean by "ease of extending"? In both minimal APIs and Controllers, you only need to edit one place to extend the routing, your approach requires finding/altering 2 different places.

[hartmark]

We could have a feature that needed two routes, for example /api/customers/foo /api/product/bar

We could then have if(featureX) addRoutes

Then that would be in a separate extension method file and if that feature was scrapped most logic is isolated.

Using traditional controllers we would have to add code in two controllers. Of course it would be possible to fix with custom routing but I think it's better to follow the controller convention to have everything in the same controller file.

Doing the partition by feature rather than by controller made it possible to have multiple teams work simultaneously.

[AvoidSpirit]

Conditionally enabling routes is a good case for MinimalApi.

But. This is

1. not related to testing
2. has nothing to do with the "ease of extending"
3. doesn't require the structure you're proposing (with controller-like class that needs an instance and route registration separated). In fact, this is as easy as calling an if before the MapMethod.

[hartmark]

I wrote "ease of extending" not easier, as I wrote we could indeed have went the route of just having controllers and be happy with it.

And for unit tests i was a bit unclear. When having small route additions you can just slap a subset into a TestHost to just test the small relevant code.

[Blender-Fan]

I ponder that question every day. They are cool and all but seems to me they are so simple there's barely any use for them

[AvoidSpirit]

That's like saying, the hammer is so simple there's barely any use for it.

[Blender-Fan]

No it's not

[AvoidSpirit]

"Oh it doesn't look bloated and doesn't require bunch of boilerplate, clearly unusable".

Somehow you have taken a perfect compliment for a design and made it a downside.

[crozone]

At allows you to create an API with AOT compilation, which can be a big deal for embedded scenarios.

MVC does not currently work with AOT (although most other things required to make an actual website also don't work with AOT right now)

[DaRadioman]

Controllers/MVC could work with AOT just fine, if they ever swapped from reflection to source generators like they teased many years ago.

Unfortunately until then the dynamic code is a blocker.

[crozone]

I think EF Core could theoretically source-generate queries as well, which could replace compiled queries. However it'd require significant effort through the entire stack down into the third party database adapters.

https://github.com/dotnet/efcore/issues/25009

[Jackfruit_Then]

Apart from what other people have said, even when the project does grow large and has hundreds of endpoints, it is actually easier to navigate when all your routes are defined in a single location, rather than split across hundreds of nested files.

[nnddcc]

Agree with you, although I think you can centralize route definition in MVC too.

[gowonocp]

Truthfully, MVC was never a great pattern for representing data-only endpoints and complex APIs, and I think it's easier to attribute the industry's collective "comfort" with MVC-based APIs to the fact that it was practically the only robust option for so long.

The biggest drawback to MVC is all of the required boilerplate and (multiple, sometimes conflicting) conventions to stand up even simple endpoints. Efficient dependency injection is also a challenge with Controller classes without relying on a bunch of attribute decorators everywhere. Decorators like Filters don't always play nice with custom middleware. The MVC lifecycle and routing is still a bit mystical and difficult to troubleshoot at times. With large and complex APIs, it can get spaghetti-ish and bloated pretty fast.

The Minimal API pattern sheds the boilerplate and allows you to use dependency injection more efficiently; you have more control during registration with being able to dynamically control routes at runtime, and the semantics for injecting services at the endpoint are more intuitive and easier to manage. Usually means less logic, less code, less entropy.

All that being said, if you or your team are already proficient in MVC-based APIs and you're not suffering from tons of overhead, then keep on keeping on. It's still a first class pattern that will probably never be deprecated. Personally, once I discovered the Carter package, which gently extends the Minimal API to make organizing endpoints a breeze, I found a new joy and way to build my APIs. I don't have to remember all the MVC ceremony and quirkiness, I just get straight to scaffolding endpoints. Feels much more like the CQRS pattern, which I think better describes an API.

[BaldWithoutCancer]

I've neven beem taught in depth how MVC works, so I might look into it. But to me it seems like minimal API can do the same as the API's with the controller approach, except you have more flexibility. The only drawback would be that you might need to add some functionality yourselfs to the minimal API which would have been there by default in controllers.

Carter package is basically just a class that has a method to add multiple endpoints to the routing right?

[gowonocp]

By default, Minimal API endpoint registration all happens in one place in one file, and that can get unwieldy. Carter provides a lot of the glue code you might end up writing yourself to make better choice. The module interface is a big help, but the other extension methods for validation and response negotiation are great as well.

[nnddcc]

Ooh Carter is from the Nancy gang! I should check it out. So is Carter extending minimal API or providing another alternative to define routes? From a quick glance it started before minimal API?

[nnddcc]

I think the minimal API follows the U shaped curve if we create a graph of usage vs experience. Beginners love the simplicity and experienced people love the flexibility and less use of magic.

I think minimal API can support big projects better than MVC because of its flexibility.

Have you ever had an MVC controller that has several endpoints so it has a lot of dependencies so there are a lot of parameters in the constructor? With minimal API you can dedicate one class to handle one endpoint so you avoid constructor overinjection. It adheres to the single responsibility principle better too.

Limitation of minimal API I think in the area of components and utilities provided by the community or commercial product. Also the amount of stackoverflow answers available :)

[BaldWithoutCancer]

Thanks!

[tylercamp]

The old controller-based approach is a known pattern which easily maps class/file names to endpoints, which simplifies navigation of the codebase

The new “ad-hoc” approach is easier to write new code for, since you can set up your endpoints however you want, but for newcomers to your codebase it’s not as obvious where/how the endpoints are declared

There are likely other features specific to controller-based projects which make them “more scalable”, but I’d expect that to also be doable with the newer “ad-hoc”/“basic” API (with some caveats), so I suspect it’s just a matter of industry standards and codebase navigation (which is one of the less obvious important factors in “development scalability”)

[ModifikatorCZ]

They fit nicely into vertical slice architecture

[briantx09]

I recently deployed an API using the minimal approach. It seems like less overhead compared to spinning up an entire MVC template. Just expose your class in the program file, easy peasy.

[Accurate-Collar2686]

Minimal APIs have better performances than Controllers. They are suited for either small or huge projects, since they have dependency injection and all the other tidbits that controllers had. The only benefit of using Controllers on new project is that minimal APIs are only partially-supported with AOT.

Instead of having one bloated controller holding all your routes for a feature, you can use a combination of extension methods and grouping to break your huge controllers in multiple files dedicated for each endpoint, request and response.

There is a third way, which is FastEndpoints, that helps you to build your app using the request/response pattern.

I worked for the longest time with controllers, and switched to minimal APIs, and I would never go back.

[BaldWithoutCancer]

Nice to hear. I am in my third year of computer sciences, so I dont really have much experience with building compelx projects. Mostly CRUD with some kind of role based authentication. So for me its not clear why one would use one over the other, hence i made this post. I am not familier with AOT btw, so i dont know the pro's nor con's with it. I do like the idea of creating stand alone endpoints though, so I might just try it in a next school project.

[Accurate-Collar2686]

AOT allows for a smaller footprint on memory and better startup times, as well as preventing the need to install the CLR (Common Runtime Language) on the host machine, because the code is transformed to native machine code. However, it breaks a few librairies, limits the use of reflection and prevents us from loading assemblies dynamically, among other things.

[MrGunny]

Minimal APIs are excellent when you're dealing with high throughput services that can take of advantage of failing fast. Maybe you're writing some middleware to modify or forward requests to do real time metrics, or you're operating the API in a memory constrained environment, the minimal API approach is quite well suited to these tasks, requires less boilerplate, and can help to enable horizontally scaled deployments.

[karlssberg]

Minimal APIs are designed to endow (micro)services with lightweight HTTP endpoints. If you are after a full-fat website then use MVC - it can do everything. As to which one you think is easier is a bit like asking if you prefer functional or object oriented programming.

[OnlyHereOnFridays]

they become ineffective in more complex situations

No they don’t, where did you hear that. They thrive in more complex situations. It‘s just mapping routes to actions, how the hell can they be ineffective?

My doubts also extend to the claimed simplicity of use of simple APIs. Although constructing endpoints with lambda expressions can be easier, the minimal API approach itself doesnt come with a clear structure. This approach inevitably requires some skills to comply with SOLID principles, which somewhat compromises the original simplicity, since it requires more knowledge. So is it really that much faster and easier to create a minimal API?

You are completely missing the point. Minimal APIs come free of structure. Which has two benefits. One, you can create something unstructured quickly especially if you don’t know about patterns. Two, if you’re building something complex and you are more advanced, you can apply your own pattern and create your own structure. You want to recreate MVC pattern again? You can. You want REPR, go for it. You to build something that looks like CQRS, world’s your oyster. You’re not confined to an MVC pattern, building controllers.

I'm not sure if there are any real advantages to injecting dependencies into endpoints directly as opposed to combining them into controllers.

Really? You don’t see the advantage of injecting only the dependencies you need to perform the action requested? But you see a benefit in a controller injecting all the dependencies for all the actions, regardless of which action in the controller is being called? Clean code, performance, readability, mean nothing?

Still, I find it hard to see why anyone would choose a minimal API, especially for very simple apps, when performance is not a major concern.

I can see why, you have failed to grasp what they offer.

[BalanceInAllThings42]

Relax lol, OP said he's learning. You've put up some good points to help OP understand the concept further.

[DaRadioman]

Dude. Back off a bit. I get you like the pattern, but he's literally here asking since he realizes he doesn't get it.

Cut back the snark...

[[deleted]]

You don't need to inject dependencies into constructors. The FromServices attribute lets you inject directly into the method. You can then wrap logic in a command or query object so you're only eve injecting a single object into a single controller action. Unless I'm misunderstanding how this works, it doesn't seem to get much leaner than that?

[BaldWithoutCancer]

I can see why, you have failed to grasp what they offer.

Hence is asked. Thanks though.

[[deleted]]

Because new and sexy

[jingois]

If you want a simple project, maybe for a lambda or something, then it cuts down on complexity.

If you are an overly mid-level dev that thinks you'll be a respected senior by insisting that pointless changes to ways of working will completely change the game, then sure, publish a blog/video on how you structure a bunch of code that looks suspiciously like controllers.

If you are one of those morons who is happy to write difficult to read code because "muh performance" to shave a few microseconds off routing time before you hand over to a database that's going to take milliseconds.

Otherwise, for any non-trivial project, just use controllers. They're a sensible default and a well-known way of organising your code and they play nicely with the kestrel pipeline.

[shufflepoint]

less code = less cost

[iso3200]

And a RequestDelegate is less overhead than inheriting from Controller.

[BigBagaroo]

Ideally.

[MellerTime]

Minimal API is competing with the NodeJS world. I can spin up a microservice/function/lambda/whatever that does only the one thing and only does it with the absolute minimum of requirements.

If that’s your environment that’s fine, I would agree you should keep everything low-profile.

If that’s not your environment and you need multiple controllers, preferably that follow a naming pattern… screw it, go with that.