Get the source code for this video for FREE → the-dotnet-weekly.ck.page/controllers-minimalapis Want to master Clean Architecture? Go here: bit.ly/3PupkOJ Want to unlock Modular Monoliths? Go here: bit.ly/3SXlzSt
I love your videos Milan. I eagerly wait for your videos every week. I like your content style and the depth with which you explain like a teacher I never had. I wish you all the success, health and happiness. Never stop making these videos man. 😊❤
Good video but I don’t think controllers need to be “fixed”. There’s nothing wrong with using controllers, it’s just another option on how you build an API. The title seems a little misleading to me, it would more accurate to title it something like “Converting you MVC API controller to minimal APIs” imo
Awesome video Milan. I do agree with not unit testing your controllers. But we should write integration/functional tests, especially on customer facing API's. Good weekend!
It just seems to be performance since it cuts out a lot of the background work the framework does for MVC. If you’re not doing MVC and simply returning JSON from some REST API, minimal APIs are tailored to that versus a controller doing the same. I don’t know what the actual gains are, that would be interesting to see!
I totally agree. I prefer and will stay with controller design. Performance boost from using minimal api is not worth it. For me code is much more clear and readable with controller approach
If controllers work for you, that's awesome. Why would you want to change that? I'm not against controllers in general. But they are easy to do wrong. I've seen so many examples of controllers with 50-100+ dependencies, and hundreds of endpoints. If you team can maintain thin controllers, more power to you. But when watching a video try to think from a different perspective. Not all developers have the same skill level as you, and they may not know how to write maintainable code. Minimal APIs are more compact, and at any point you're working with a single endpoint. So there is less room for error.
We start learning something, that time that seems shining and commonly used across the community. After some time that becomes obsolete and another thing starts shining and being talked about everywhere, we are caught in a trap of never ending process 😂
We start learning something, that time that seems shining and commonly used across the community. After some time that becomes obsolete and another thing starts shining and being talked about everywhere, we are caught in a trap of never ending process 😂
There are use cases for both. Experience with one or the other also plays a role. I'm not saying you replace all your controllers with Minimal APIs. But if you're starting a new project, at least give it a thought.
@milanJovanovicTech . Great video I guess its a case of different strokes for different folks....folks in this case are projects. Minimal API is a tool in the toolbox, you might use or not. on to the next one
Thank you for the great video! The only thing, I didn't get point of using carter. First of all, anyway I have to not forget to mark my class with ICarterModule, then it's bring unclear behaviour to the class, because for me it's not obvious, that AddRoutes internally would register my endpoints class, and the last but not least, it's external dependency. Maybe I missed something?
I didn't express my thought quite correctly(English isn’t very well). As the complexity of the project increases, the code using the minimal api will become more and more similar to the code using controllers, I think.
Excellent video! Would you still use Mediatr with minimal endpoints? Seems you can just inject the class you need and call that. You won't need to deal with many dependencies not relevant to the specific endpoint, like we need in controllers case.
Mediatr has the advantage of a pipeline with behaviors. But sure, if all you are doing is calling a handle method of a class and passing the command, mediatr isn't really needed.
Interesting. I'll need to try this out. One question though: you did not mention (custom) attribues. How do they convert to minimal api if they're on controller or method level? Thanks.
@@anilkarasahh If you _have_ to use Attributes and cannot use "Endpoint filters" which are must much powerful (google them if you are interested, I have terrible experiences with trying to post links on UA-cam; No feedback and my comments just gets deleted after like 10 seconds), then you can simply add them to the Lambda itself: app.MapGet("/HelloWorld", [MyCustomAttributeThatReallyShouldBeAnEndpointFilter] (HttpContext httpContext) => {...logic here};
You place attributes on the request delegate. Additionally, you can add them as metadata: github.com/Treblle/treblle-net-core/blob/master/TreblleCore/RouteHandlerBuilderExtensions.cs
@@MilanJovanovicTech Nice content. I won't say it is more complex I but do not find it simpler either. You do basically the same thing using an approach we are not used to. You started with MapControllers and a class inheriting from Controller that has the route definitions and methods to process HTTP requests by returning IActionResult. You end up with MapCarter and a class implementing a ICarterModule that has the route definition and methods to process HTTP requests by returning IResult. The shape of the code is the same (and you introduced a dependency to a third party library).
Awesome video, I didn't realise that using the Results inferface is almost like a discriminated union, very nice. What do you think about using carter to separate each endpoint into a separate class, like the handler command/handler approach used with MediatR, or is this overkill? Interested to get your opinion.
Seems a bit overkill indeed since these endpoints shouldn't hold the business logic. Rather orchestrate. The options shown in this video are pretty good, the vertical or maybe even modular approach. If you'd want to keep your business logic independent from AspNetCore framework, you could split those projects into one for the business logic and one for the minimal API.
Hi Milan, If we implemented the minimal api with the help of ICarter, we are able to call our endpoint. In such scenarios, I am going to implement the api versioning, how to pass the VersionSet value into the endpoint.
Here are a bunch of examples for API versioning, and some of them are related to Minimal APIs: github.com/dotnet/aspnet-api-versioning/tree/3857a332057d970ad11bac0edfdbff8a559a215d/examples/AspNetCore/WebApi
The video in short: Controllers are bad and wasteful. But we can do functionally the same with minimal API (although we could do exectly the same stuff with parameter injection and so on with controllers). However, to use it we have to implement an ammount of custom methods or use some third-party library. But now we do not use controllers. Why? I don't get the point. Really. With a wise approach you can use controllers without memory loss or injecting unnecessary stuff. Moreover, it is more convenient to auto-generate swagger by controller xml-docs (rather than do tricks with MinAPI). Basically, what I want to say is that the claim that MinAPI is definitely better than controllers is false
@@MilanJovanovicTech no one prevents you from structuring controllers as you want. They are effectively just routing groups. So if you see that your controller consists of actions that should not be together, then just split it. A controller can even consists of a singular action. That is fine. But you can also describe "sibling" methods, that, for example, use same set of services (like, loggers or db contexts) and describe them in a single class. That also prevents you from duplicating same injections (you can move them to the constructor), but doesn't prevent you in any way to specify services unique for a certain action (and inject it via FromServicesAttribute). Once again. I do not say that MinAPI is evil or controllers are the best and everyone should use them. But I just want to be honest and mention that it all depends. Depends on your cases. Depends on complexity of your domain. What I saw in this video was mostly about "how we can implement same structure as for controllers, but without controllers". I didn't see (particularly in this scenario) the reason why we should do it. We changed nothing here, except now our logic is static and we can call it from everywhere else. But again there is not a reason for that. At least I don't see it (maybe I'm wrong).
I don't really like the group method, better left it full route, so when you found errornin the logs, you can debug by copypaste the URL to find your entry point controller
@@MilanJovanovicTech yes, like `/api/v1/schools/{id}/classes/{class_id}/students/{student_id}` It's more verbose but it's easier to debug. You can log that route spec, and then when debugging you can just copy paste that route to find your controller
Thank you. I did'nt know about grouping minimal Apis and the strong typed result. However, I do not like Carter because it's a dependency to be lazy as developer. I mean you would know very soon, when you forget to register a group of minimal apis.
Awesome content Milan as always, I have been a silent content consumer of your channel and it just pains me to see weird criticism from people who don't appreciate the quality of content just wanted to ask how this would work with swagger configuration like producesresponsetype etc will it get a bit clunky?
Depends on your workload and what you are doing, but it can offer a noticeable improvement in throughput. I'll do video discussing performance with benchmarks. The memory allocation of Minimal APIs is also reduced.
I think minimal APIs lack in ways to make good API documentation. Now you need to work with an array of arguments and modify their properties instead of adding XML comments, status code descriptions using attributes, and so on.
1.why would you even need to POLUTE your project with this carter library? it takes a misery amount of code to implement the same yourself. 2.controllers are still better for documenting your APIs. Powerful attributes like [SwaggerResponse] and comments are still more convenient to use in controllers. And this is crucial for any serious project with documented apis.
1. Why would I reinvent the wheel? Plus it has some pre-post request middleware that can be useful. 2. You can use them just the same with Minimal APIs - except you need to call methods for each endpoint
Minimal APIs have all the same Swagger support but with method calls rather than attributes. But so far I haven't seen any missing from Controller based api documentation.
If your controller is growing exponentially then that itself is a design problem and not an issue with controllers. If you put your order , Catalog , invoice APIs in one controller surely that controller has a lot of code that is not needed for all APIs but that is just poor design choice
Hm you just converted a Controller into a Minimal API which uses more Boilerplate than before and has no benefit at all. Im sorry but you stated at the beginning "For more cohesion and performance" but you doesnt show it. The only difference is the Method Injection instead of Constructor but thats i can do in an old fashioned Controller aswell. Based on your example here i see no reason why i should switch to Minimal APIs. There might be benefits but it would be helpfull if you really point them out.
When you encounter controller with 20+ endpoints, and some of them have anything than the simplest logic inside, it starts making a lot of sense. You can easily have one endpoint per file, with complete request/response classes. Your whole feature in one place. Albeit, not many people still appreciate this aspect, nor do they enjoy moving away from controllers. I talked about it briefly here: www.milanjovanovic.tech/blog/vertical-slice-architecture
@@MilanJovanovicTechThank you for your answer. I can agree with you to some extend. I just want to point out that moving to minimal api is not the only solution to this. For example if i have more than 20 endpoints in one file i would first ask the question if they really belong together or if there better ways to structure the api and i would ask this regardless the api approach. Another way to solve this would be to use partial classes. Anyway the main topic i really learn from this video was how to structure minimal apis. This was a thing i wasnt sure about how to handle it at all.
Here's a benchmark from FastEndpoints: fast-endpoints.com/benchmarks#head-to-head-benchmark You can see Minimal APIs are ~40%ish faster than controllers
According to MS docs Minimal API doesn't have model binding and validation, doesn't support view rendering So you can not replace ANY controller you want with minimal API.
Actually, the dotnet team didn't create the Minimal API to tell us we must switch from controllers to minimal api. Minimal API is just a simple way for testing and making a very small project faster without needing to create controllers and so on. It's just bunch of extensions methods that are using the same features that have been already existed before. It was also a copy of minimal apis from NodeJs and other languages & frameworks. People wanted to make a small API project very fast and easy with just a few lines of codes, so the Dotnet team added the extension methods to achieve this.
"It's just bunch of extensions methods that are using the same features that have been already existed before." - I don't think it's that simple under the hood
Many of the points you are doing in the begging are not valid. You should not put all of your logic in a single controller. If you have services that are not used or used by few methods then pull them out in a separate controller class.
Thanks for the journey, you've come a long way, and I have enjoyed your content, but I just can't respect a creator that needs stupid thumbnails and click bait headings. this is a trend that might gain views in the short term, but do you really want views from people with no self control or gain a following that comes back again and again for the content? I'm sorry, unsubscribed.
Sorry but I have to jump in. I agree 100% with your opinions on click bait titles, annoying likes and subscribe "in your face" pop-ins. But first I'd be curious to understand what makes you think this video has a click bait title 😳.. But most important, you're missing the only thing that matters.. Is the content valuable? Did you learn something? Do you think the author worked hard to share quality content or just did a copy/paste of a previous tutorial ? I feel sorry for you, everyone has his opinion and we are all free to disagree with Milan's opinions.. but he deserves at least respect and he is definitely not a click baiter ! I wish I could produce half what he's bringing to the community. That being said, keep up the good work Milan. This video was awesome for me, and just in time, as I currently need to find quick and actionable tips to get away from controllers 👍🙏 Just ignore the haters and lousy voices. Inevitable sadly, whoever you are and you do. I'm pretty sure Gandhi, Dr Martin Luther King, Nelson Mandela,.. and all the great people who fought as a force of good would get their share of haters in social media. But I disgress 😂 Stay awesome, and thank you
Apologies if that came across as a "hater", that was not my intent, hence the thanks. And yes Milan's content is usually of a high standard, and I agree does deserve all his subscribers. I am finding most social media platforms these days toxic and have been leaving most of late. I wish you all the best, particularly Milan, and hope you all thrive with the content presented.
@@S3Kglitches If anything it's easier - because the dependencies for each endpoint are clear. In a controller, all dependencies are shared between endpoints.
The title promises "better performance," and it must be (for the sake of Milan's authority) evident somewhere between the lines and words in the content.
Good stuff! I need to learn your presentation style, so to the point. What does the CarterModule internally do? Grabbing all those IEndpointBuilder usages?
Get the source code for this video for FREE → the-dotnet-weekly.ck.page/controllers-minimalapis
Want to master Clean Architecture? Go here: bit.ly/3PupkOJ
Want to unlock Modular Monoliths? Go here: bit.ly/3SXlzSt
I love your videos Milan. I eagerly wait for your videos every week. I like your content style and the depth with which you explain like a teacher I never had. I wish you all the success, health and happiness. Never stop making these videos man. 😊❤
Thank you so much, Vivek! You made my day :)
Milan you are doing a great job, very very to-the-point videos and too much content are covered in a very short time. Thank you.
Thanks a ton
Good video but I don’t think controllers need to be “fixed”. There’s nothing wrong with using controllers, it’s just another option on how you build an API. The title seems a little misleading to me, it would more accurate to title it something like “Converting you MVC API controller to minimal APIs” imo
I need to balance between CTR and content 😅
You are 100% correct
Awesome video Milan. I do agree with not unit testing your controllers. But we should write integration/functional tests, especially on customer facing API's. Good weekend!
Thanks a lot, Thomas. We're on the same page with testing 👌
I didn't get why should I use this instead of controllers. Doesn't make sense in my head using this if I'm making a CRUD.
It just seems to be performance since it cuts out a lot of the background work the framework does for MVC. If you’re not doing MVC and simply returning JSON from some REST API, minimal APIs are tailored to that versus a controller doing the same.
I don’t know what the actual gains are, that would be interesting to see!
I totally agree. I prefer and will stay with controller design. Performance boost from using minimal api is not worth it. For me code is much more clear and readable with controller approach
Agree. Also I have feeling that this minimal stuff would put a knife in your back when you need to do some specific stuff
If controllers work for you, that's awesome. Why would you want to change that?
I'm not against controllers in general. But they are easy to do wrong.
I've seen so many examples of controllers with 50-100+ dependencies, and hundreds of endpoints.
If you team can maintain thin controllers, more power to you.
But when watching a video try to think from a different perspective.
Not all developers have the same skill level as you, and they may not know how to write maintainable code.
Minimal APIs are more compact, and at any point you're working with a single endpoint. So there is less room for error.
We start learning something, that time that seems shining and commonly used across the community. After some time that becomes obsolete and another thing starts shining and being talked about everywhere, we are caught in a trap of never ending process 😂
Thank you so much for taking your time to create such a great explaination. Cheers, buddy!
Glad it was helpful! My pleasure :)
Thank you very much for the video, really glad that your channel is growing, you came a long way, you deserve more.
Thanks a lot, I have some amazing things planned for the coming months 😁
@@MilanJovanovicTech glad to hear that, looking forward to see more amazing stuff from you.
We start learning something, that time that seems shining and commonly used across the community. After some time that becomes obsolete and another thing starts shining and being talked about everywhere, we are caught in a trap of never ending process 😂
There are use cases for both. Experience with one or the other also plays a role. I'm not saying you replace all your controllers with Minimal APIs. But if you're starting a new project, at least give it a thought.
Yeah, I would try that. And I like your contents. You are just bringing what is floating in the community and you are demonstrating them quite well.
Very nice video, extremely simple explaining. I love your contents. Go on Milan! 💯
Thank you so much 😀
Awesome video Milan, you teaching style is great, Keep posting such content and do not stop....😍
Thank you so much 😀
Thanks, Milan, This is what I'm looking for.
When did Andrew Tate start coding? 😁
@@MilanJovanovicTech i just sold my bugatti 😂😂
Great Tutorial!
Thanks a lot, glad you liked it :)
Thanks alot. straightforward and useful video. ✌️
Awesome, glad you enjoyed it ;)
Thank you Milan!
You're welcome!
@milanJovanovicTech . Great video
I guess its a case of different strokes for different folks....folks in this case are projects.
Minimal API is a tool in the toolbox, you might use or not.
on to the next one
I completely agree
Would love to see a minimal API example that handle login and register endpoints in DDD environment that uses an AuthorizationService.
Have some samples:
- ua-cam.com/video/xBuLWaDcvu0/v-deo.html
- ua-cam.com/video/4cFhYUK8wnc/v-deo.html
Thanks, Milan, This is useful and it's exactly what I was looking for.
You're welcome!
Great straightforward aproach in this video. Keep up the good work. Liked, subbed for all.
Thanks a lot, Daniel! :)
Thanks a lot Milan, you are awesome. keep going 👍
Thanks, will do! :)
amazing video and very helpful tnx
Glad it helped
very good, thank you very much for sharing
Glad you enjoyed it
Yes this is a really valuable one
Glad you found it valuable 💪
What if I use mediatr and only use mediatr as a service in my controllers, and the actual implementation is outside the presentation layer?
So just use it to send commands/queries?
@@MilanJovanovicTech Isn't that what Ardalis (Steve Smith) is doing with the REPR pattern?
Good stuff! Thanks!
Glad you liked it!
Thanks man for the video
You bet
Very interesting video. Thank you Milan!
My pleasure!
That was really good - have you done security on Minimal API's
Haven't released anything yet, have some projects in the pipeline
Thank you for the great video!
The only thing, I didn't get point of using carter. First of all, anyway I have to not forget to mark my class with ICarterModule, then it's bring unclear behaviour to the class, because for me it's not obvious, that AddRoutes internally would register my endpoints class, and the last but not least, it's external dependency. Maybe I missed something?
How would you implement it?
That's a great video about the minimal api
Glad you liked it!
thank you very much, i'll be using minimal apis from now on for my API routes
Awesome!
Why? This looks like an invention of controller in perspective with increasing of complexity. Keep it minimal.
How does it increase complexity?
I didn't express my thought quite correctly(English isn’t very well). As the complexity of the project increases, the code using the minimal api will become more and more similar to the code using controllers, I think.
Excellent video!
Would you still use Mediatr with minimal endpoints? Seems you can just inject the class you need and call that. You won't need to deal with many dependencies not relevant to the specific endpoint, like we need in controllers case.
Mediatr has the advantage of a pipeline with behaviors. But sure, if all you are doing is calling a handle method of a class and passing the command, mediatr isn't really needed.
MediatR has many more features than just passing commands/queries, which I find useful. So that's why I'm using it so extensively.
@@MilanJovanovicTech Are there any videos available or planned in future regarding the many uses of MediatR other than command/query handling?
Thank you sir for this valuable information... and all for free!
Most welcome!
You are amazing!!!!!
Thanks a lot!
Excelente video
Thanks!
Interesting. I'll need to try this out. One question though: you did not mention (custom) attribues. How do they convert to minimal api if they're on controller or method level? Thanks.
I was looking for an answer to this question as well. I'm parking here :D
@@anilkarasahh If you _have_ to use Attributes and cannot use "Endpoint filters" which are must much powerful (google them if you are interested, I have terrible experiences with trying to post links on UA-cam; No feedback and my comments just gets deleted after like 10 seconds), then you can simply add them to the Lambda itself:
app.MapGet("/HelloWorld", [MyCustomAttributeThatReallyShouldBeAnEndpointFilter] (HttpContext httpContext) => {...logic here};
@@anilkarasahh It's a free parking zone my man :)
添加终结点筛选器
You place attributes on the request delegate. Additionally, you can add them as metadata: github.com/Treblle/treblle-net-core/blob/master/TreblleCore/RouteHandlerBuilderExtensions.cs
What is really the advantage of going to route? The code looks way complex that the normal controller endpoint.
How is it more complex?
@@MilanJovanovicTech Nice content. I won't say it is more complex I but do not find it simpler either. You do basically the same thing using an approach we are not used to.
You started with MapControllers and a class inheriting from Controller that has the route definitions and methods to process HTTP requests by returning IActionResult.
You end up with MapCarter and a class implementing a ICarterModule that has the route definition and methods to process HTTP requests by returning IResult.
The shape of the code is the same (and you introduced a dependency to a third party library).
Very clear !
Ty!
Subscribed because I liked this video very much and willing to learn the minimal api, but do you know someone using it in production?
Well, I used it in production. But that's a sample size of 1 :)
I like controller base api
We all do 😁
This is very good, but how do I define FromRoute, FromQuery, FromBody using this?
You can use the attributes in the Minimal API request delegate ([FromQuery] MyQueryDto dto1, [FromBody] MyBodyDto dto2) => {}
I can't stop laughing at the thumbnail 🤣
A real work of art. I'm pretty happy with how it turned out 😉
Awesome video, I didn't realise that using the Results inferface is almost like a discriminated union, very nice. What do you think about using carter to separate each endpoint into a separate class, like the handler command/handler approach used with MediatR, or is this overkill? Interested to get your opinion.
Seems a bit overkill indeed since these endpoints shouldn't hold the business logic. Rather orchestrate.
The options shown in this video are pretty good, the vertical or maybe even modular approach. If you'd want to keep your business logic independent from AspNetCore framework, you could split those projects into one for the business logic and one for the minimal API.
I don't think it's overkill. It's something I did in the VSA video.
Hi Milan,
If we implemented the minimal api with the help of ICarter, we are able to call our endpoint. In such scenarios, I am going to implement the api versioning, how to pass the VersionSet value into the endpoint.
Here are a bunch of examples for API versioning, and some of them are related to Minimal APIs: github.com/dotnet/aspnet-api-versioning/tree/3857a332057d970ad11bac0edfdbff8a559a215d/examples/AspNetCore/WebApi
How would you use an custom AuthorizationAttribute in minimal API's?
You can create an attribute, and add it as metadata: github.com/Treblle/treblle-net-core/blob/master/TreblleCore/RouteHandlerBuilderExtensions.cs
@@MilanJovanovicTech Thank you! Keep on the good work :)
what were you scared of in the thumbnail? :p , good vid
The people defending controllers in the comments 😂
The video in short:
Controllers are bad and wasteful. But we can do functionally the same with minimal API (although we could do exectly the same stuff with parameter injection and so on with controllers). However, to use it we have to implement an ammount of custom methods or use some third-party library. But now we do not use controllers.
Why?
I don't get the point. Really. With a wise approach you can use controllers without memory loss or injecting unnecessary stuff. Moreover, it is more convenient to auto-generate swagger by controller xml-docs (rather than do tricks with MinAPI). Basically, what I want to say is that the claim that MinAPI is definitely better than controllers is false
What about cohesion? Minimal APIs make it easy to implement REPR
@@MilanJovanovicTech no one prevents you from structuring controllers as you want. They are effectively just routing groups. So if you see that your controller consists of actions that should not be together, then just split it. A controller can even consists of a singular action. That is fine. But you can also describe "sibling" methods, that, for example, use same set of services (like, loggers or db contexts) and describe them in a single class. That also prevents you from duplicating same injections (you can move them to the constructor), but doesn't prevent you in any way to specify services unique for a certain action (and inject it via FromServicesAttribute).
Once again. I do not say that MinAPI is evil or controllers are the best and everyone should use them. But I just want to be honest and mention that it all depends. Depends on your cases. Depends on complexity of your domain. What I saw in this video was mostly about "how we can implement same structure as for controllers, but without controllers". I didn't see (particularly in this scenario) the reason why we should do it. We changed nothing here, except now our logic is static and we can call it from everywhere else. But again there is not a reason for that. At least I don't see it (maybe I'm wrong).
👋👋
Sweet......🤗
Thanks!
I don't really like the group method, better left it full route, so when you found errornin the logs, you can debug by copypaste the URL to find your entry point controller
Do you specify the entire route with controllers?
@@MilanJovanovicTech yes, like `/api/v1/schools/{id}/classes/{class_id}/students/{student_id}`
It's more verbose but it's easier to debug. You can log that route spec, and then when debugging you can just copy paste that route to find your controller
The usage of static does not increase the memory footprint?
Not considerably
@@MilanJovanovicTech Okay so there's an increase in footprint, there's a way to not use static classes and methods with minimal APIs?
very nice
Thanks
Thank you. I did'nt know about grouping minimal Apis and the strong typed result.
However, I do not like Carter because it's a dependency to be lazy as developer.
I mean you would know very soon, when you forget to register a group of minimal apis.
Carter helps so that you don't have to remember - it just works 😁
Excellentoooooo
Thank you sir!
Good video, but which problem did you actually solve?
Refactoring from controllers to Minimal APIs
@xskyaflake it's not solving anything, rather, finding problem to a solution.
Awesome content Milan as always,
I have been a silent content consumer of your channel and it just pains me to see weird criticism from people who don't appreciate the quality of content
just wanted to ask how this would work with swagger configuration like producesresponsetype etc will it get a bit clunky?
There's a method which you can call: ProducesResponseType
So instead of an attribute, you call a method.
How much faster is this? Looks pretty unpolished and complicated compared to the controllers.
Depends on your workload and what you are doing, but it can offer a noticeable improvement in throughput. I'll do video discussing performance with benchmarks.
The memory allocation of Minimal APIs is also reduced.
@@MilanJovanovicTech Awesome, I love to see video to compare the performance and memory allocation compare between controllers and minimal APIs.
Does anyone measure the performance of controllers and minimal APIs, what is the difference?
I'll make a video about it!
@@MilanJovanovicTech Cool. Looking forward!
Minimal APIs when grows larger in size start to look like controller. Keep it minimal.
Endpoints should be minimal regardless.
What is the name of the theme u use for your ide?
R# dark theme (ReSharper)
@@MilanJovanovicTech Been Looking for a while, Thanks !
Nice video mate. Still I don’t like this minimal api. I find it so damn annoying
That's fine, we have options in .NET and we can decide what works for our projects 😁
I tried this but my JoyCons still won't reattach to my Switch 😛
Ah, crap! Unintended bug
I think minimal APIs lack in ways to make good API documentation. Now you need to work with an array of arguments and modify their properties instead of adding XML comments, status code descriptions using attributes, and so on.
That's true, a possible disadvantage
1.why would you even need to POLUTE your project with this carter library? it takes a misery amount of code to implement the same yourself.
2.controllers are still better for documenting your APIs. Powerful attributes like [SwaggerResponse] and comments are still more convenient to use in controllers. And this is crucial for any serious project with documented apis.
1. Why would I reinvent the wheel? Plus it has some pre-post request middleware that can be useful.
2. You can use them just the same with Minimal APIs - except you need to call methods for each endpoint
Minimal APIs have all the same Swagger support but with method calls rather than attributes. But so far I haven't seen any missing from Controller based api documentation.
@khalilovk they are finding problem to a solution. Lol
Indeed this is really useful video on how to refactor old API. Can you make a video on how to use Auth with minimal API?
Will do!
@@MilanJovanovicTech Thanks a lot. It would be interesting with roles.
Thanks for that one, I'll refactor my controllers asap 😅
Oh god, now your boss will be calling me 😂
If your controller is growing exponentially then that itself is a design problem and not an issue with controllers. If you put your order , Catalog , invoice APIs in one controller surely that controller has a lot of code that is not needed for all APIs but that is just poor design choice
That is true
Hm you just converted a Controller into a Minimal API which uses more Boilerplate than before and has no benefit at all. Im sorry but you stated at the beginning "For more cohesion and performance" but you doesnt show it. The only difference is the Method Injection instead of Constructor but thats i can do in an old fashioned Controller aswell. Based on your example here i see no reason why i should switch to Minimal APIs. There might be benefits but it would be helpfull if you really point them out.
When you encounter controller with 20+ endpoints, and some of them have anything than the simplest logic inside, it starts making a lot of sense. You can easily have one endpoint per file, with complete request/response classes. Your whole feature in one place. Albeit, not many people still appreciate this aspect, nor do they enjoy moving away from controllers. I talked about it briefly here: www.milanjovanovic.tech/blog/vertical-slice-architecture
@@MilanJovanovicTechThank you for your answer. I can agree with you to some extend. I just want to point out that moving to minimal api is not the only solution to this. For example if i have more than 20 endpoints in one file i would first ask the question if they really belong together or if there better ways to structure the api and i would ask this regardless the api approach. Another way to solve this would be to use partial classes. Anyway the main topic i really learn from this video was how to structure minimal apis. This was a thing i wasnt sure about how to handle it at all.
I just dont like this, idk why minimal and static api's like harding code. Is any performance testing on there?
Here's a benchmark from FastEndpoints: fast-endpoints.com/benchmarks#head-to-head-benchmark
You can see Minimal APIs are ~40%ish faster than controllers
Thank you milan!@@MilanJovanovicTech
According to MS docs Minimal API doesn't have model binding and validation, doesn't support view rendering
So you can not replace ANY controller you want with minimal API.
This is for APIs (it's in the name)
Actually, the dotnet team didn't create the Minimal API to tell us we must switch from controllers to minimal api.
Minimal API is just a simple way for testing and making a very small project faster without needing to create controllers and so on.
It's just bunch of extensions methods that are using the same features that have been already existed before.
It was also a copy of minimal apis from NodeJs and other languages & frameworks. People wanted to make a small API project very fast and easy with just a few lines of codes, so the Dotnet team added the extension methods to achieve this.
"It's just bunch of extensions methods that are using the same features that have been already existed before." - I don't think it's that simple under the hood
Your code is very complicated !!! Current apis controller is more simple
We all have preferences 🤷♂️
Many of the points you are doing in the begging are not valid. You should not put all of your logic in a single controller. If you have services that are not used or used by few methods then pull them out in a separate controller class.
Those are fair points that make sense. In practice, I've rarely (if ever) seen that done.
Seriously? Converting Controllers to minimal APIs? You are finding problems with a solution.
Someone out there will want to migrate from controllers to Minimal APIs
It's an alternative, not a replacement. It makes more sense when you don't have simple MVC-style CRUD-based apps due to its flexibility.
Thanks for the journey, you've come a long way, and I have enjoyed your content, but I just can't respect a creator that needs stupid thumbnails and click bait headings. this is a trend that might gain views in the short term, but do you really want views from people with no self control or gain a following that comes back again and again for the content? I'm sorry, unsubscribed.
I'm sorry you feel that way. I wish you a heartfelt goodbye. Stay awesome!
What a bizarre comment. Grow up dude.
Sorry but I have to jump in. I agree 100% with your opinions on click bait titles, annoying likes and subscribe "in your face" pop-ins.
But first I'd be curious to understand what makes you think this video has a click bait title 😳..
But most important, you're missing the only thing that matters.. Is the content valuable? Did you learn something? Do you think the author worked hard to share quality content or just did a copy/paste of a previous tutorial ?
I feel sorry for you, everyone has his opinion and we are all free to disagree with Milan's opinions.. but he deserves at least respect and he is definitely not a click baiter ! I wish I could produce half what he's bringing to the community.
That being said, keep up the good work Milan. This video was awesome for me, and just in time, as I currently need to find quick and actionable tips to get away from controllers 👍🙏
Just ignore the haters and lousy voices. Inevitable sadly, whoever you are and you do. I'm pretty sure Gandhi, Dr Martin Luther King, Nelson Mandela,.. and all the great people who fought as a force of good would get their share of haters in social media. But I disgress 😂
Stay awesome, and thank you
@@wmalgoire Not speaking for the OP, but maybe because of the word "Fix". There's nothing "broken" about controllers.
Apologies if that came across as a "hater", that was not my intent, hence the thanks. And yes Milan's content is usually of a high standard, and I agree does deserve all his subscribers. I am finding most social media platforms these days toxic and have been leaving most of late.
I wish you all the best, particularly Milan, and hope you all thrive with the content presented.
sorry no
Why?
@@MilanJovanovicTech for large real world apps it's unusable and unmaintainable
@@S3Kglitches If anything it's easier - because the dependencies for each endpoint are clear.
In a controller, all dependencies are shared between endpoints.
This is awesome! Thanks!
Glad you found it valuable! :)
The title promises "better performance," and it must be (for the sake of Milan's authority) evident somewhere between the lines and words in the content.
All else being equal, Minimal APIs have more throughput (= better performance)
Thank you so much for this excellent video. This is exactly what I need to do.
Glad it was helpful!
bless you.
Thanks!
Good stuff! I need to learn your presentation style, so to the point. What does the CarterModule internally do? Grabbing all those IEndpointBuilder usages?
Yea, basically. It's open source so you can view the code.
Maybe I'll implement a Carter clone in a future video to show how simple the concept is.