How To Organize Minimal API Endpoints Inside Of Clean Architecture
Vložit
- čas přidán 27. 07. 2024
- Get the source code for this video for FREE → the-dotnet-weekly.ck.page/org...
☄️ Master the Modular Monolith Architecture: bit.ly/3SXlzSt
📌 Accelerate your Clean Architecture skills: bit.ly/3PupkOJ
🚀 Support me on Patreon to access the source code: / milanjovanovic
Minimal APIs have been a great addition to ASP.NET Core in .NET 6. However, there isn't clear guidance on how to organize your minimal API endpoints. I want to offer you two solutions for that problem in this video, and I'll use Clean Architecture as an example.
How To Structure Minimal APIs
www.milanjovanovic.tech/blog/...
Join my weekly .NET newsletter:
www.milanjovanovic.tech
Subscribe for more:
czcams.com/users/MilanJovano...
Chapters
0:00 Minimal API endpoints
1:03 Grouping endpoints with Extension methods
3:25 Grouping endpoints with Modules
4:38 Carter Modules - Věda a technologie
Get the source code for this video for FREE → the-dotnet-weekly.ck.page/organize-minimalapis
Want to master Clean Architecture? Go here: bit.ly/3PupkOJ
Want to unlock Modular Monoliths? Go here: bit.ly/3SXlzSt
Hi Milan, I would like to THANK you for your effort sharing your knowledge and research information you share with us. I found this video very very useful for me cause I currently started an project with Minimal API and here is exactly what I needed to resolve. Hope you'll continue to provide new videos & tutorials to US. Thanks again!
Great, happy to hear it helped someone
I always wait for your videos. Your videos are full of information and the way you explain is simply awesome!!!
Thank you so much 😀
I would really love to see a video on expanding the clean arch project into a collection of projects with their own endpoints (modular monolith) exploring how to communicate between the different modules
maybe this is helpful for you czcams.com/video/1IE8RC-IOSE/video.html
That's on the radar, I just need some time 😁
Your contents are always very rich for me. I really appriciate them. Thank you Milan
My pleasure!
Thanks for share Milan! I hope in the future you will talk about DTO and Mapping with entities inside of Clean Architecture!!
Perhaps, I don't think it's a "big" topic though
Thanks for the great content. I've watched some of your videos about clean architecture which helped me a lot to understand the topic.
Awesome, happy to help! :)
Thanks Milan, you awesome. keep it up 👍
Thanks, will do!
Thanks for a great video!
You're welcome :)
Thanks
Don't mention it ;)
great stuff. do some videos on cloud(azure) related work. like function apps, working with storages, best practices, project set up etc. great stuff as greatness comes from awesomeness :)
I have all that planned, don't worry. Just can't release 20x videos in a day 😂
Hi Milan, looks clean and like a winning plan. The latest version includes support for authorization which is a must have. I'll try it in my new project.
Take a look at this for a simplified implementation: www.milanjovanovic.tech/blog/automatically-register-minimal-apis-in-aspnetcore
Hi, great content! Could you elaborate on the `request.Adapt` approach? Is `.Adapt` just an extension method?
Yes, and it comes from the Mapster library to do a dynamic mapping
you are a great
Thanks!
First vid I've seen, good structured info, really like to get into the clean architecture and minimal API's (as others said it's on the hype train nowadays). Still not sure how this would work with the microservice architecture which I'm also a fan of, as it feels like a lot of different functionality would go into a minimal API when you have 100-200 routes lol
I think I'll have to expand on this project to beef it up with a lot of endpoints, and then we'll see if I start hurting 😂
@@MilanJovanovicTech Hehe looking forward to it😁 but what is your thoughts on microservices vs minimap api's?
@@kevinbeye6263 Well, microservices are a system architecture. Minimal APIs are a just a way to implement endpoints. How do we compare them?
One of my problems was: How to maintain a minimal segmented API? Thanks for this video
Glad it was helpful!
Now, How to implement Versioning with Carter? or Not Apply this method@@MilanJovanovicTech
Its really great Milan.
@Milan, is there any way to Implement endpoint for specific roles like [Authorize(Roles="role1,role2")] ?
Yes, you can apply the Authorize attribute to the endpoint lambda expression.
Or you can call the method on the IEndpointRouteBuilder to add authorization
@4:05 If you make the IModule's RegisterEndpoint abstract static then your ProductsModule can remain a static class, so you don't need to create an instance of it to register the endpoints.
What would that imply when fetching the implementations of IModule? 🤔
@@MilanJovanovicTech I mentioned it as you said you had to change the ProductsModule to no longer be a static class so it could implement the interface, but that is possible using abstract static in the interface. But why it might be useful in this scenario is that not creating an instance would avoid the need to garbage collect them afterwards. As the project grows and you potentially have lots of Modules, that clean up after scaffolding could slow down your start up time, which is less than ideal in a serverless setup for example. The performance hit might be negligible, but if what you're doing can be done without requiring an instance then it's an option.
Hi Milan, I really apreciate it your content, its just that i need. I have a question... Carter support Native AOT?
No idea
4th option - go back to the controllers, as all these approaches are actually ways to mimic the same outcome.
5th option - structurize it like you'll do it in expressJs
My 2 cents regarding this one - minimal API is great when you have just few endpoints, but when you will get to 100 (the reference number you used) is better to stick to the controllers.
This might be subject to an ADR (architecture decision record) in a real world project 😉
I'm just wondering why you think endpoints are so different from controllers that maintaining 100-200 endpoints would be any different? 🤔
From the Microsoft documentation:
"Minimal APIs are architected to create HTTP APIs with minimal dependencies. They are ideal for microservices and apps that want to include only the minimum files, features, and dependencies in ASP.NET Core."
With this in mind and the fact that the controllers already offer a well-known, and mature, oriented around functional parts it's easier to scale the development and maintainability. Also from the security point when talking about authZ is easier to tackle this at the controller level than in the minimal API approach. Unit testing the minimal approach it's possible depending on the approach, but feels unnatural, and this is probably for the best as the API layer should be devoid of any application or business logic and should focus primarily on a few concerns.
What I do not like at the controllers is the fact that I get all dependencies for functionalities I do not require in specific flows, and in the minimal API this is already "fixed".
Considering the fact that you have between 100-200 endpoints in an API I would question its architecture. Is this a monolith, or is an API domain oriented which should do only that specific stuff and nothing else?!?
As an example dealing with customers means you need to be able to create, update, delete, disable, filter, and find a customer - this will be roughly 10 possible endpoints. Of course, in some cases, the situation might be a bit more complicated than that but that will depend on the given context.
So as always in software architecture everything is a tradeoff as you will win some, and you will lose some ...
I thought about 4th option at first as well. This looks to restore the (Api)Controller behaviours that were avaiable there. But Minimal API's are more of an opt-in setup whereas Controllers gave you everything, even when you didn't need it.
So, yes this video tries to restore some of the behaviour that was already present in controllers, but NOW you get it in a leaner way where you only get/use the things you are interested in.
It's not that controllers were bad, it's just they gave you -- in certian use-cases -- a lot of things you did not need.
@Milan Nice video, you always make me think twice (or more) on what you explain and most of the times, even when I don't agre at first I have to revise my opinion and DO agree whit what you say. Keep up the good work, I really enjoy your videos
Have your tried the FastEndpoints library for organising minimal APIs? Which one do you like more?
I didn't try it
nice video once again my main problem with minimal apis is that microsoft is trying the "node" way of building apis and for me doesn't really suit it. I will only use this if im doing a hobby project or trying stuff up but in a real world enteprise application im not really using it. Whats your thoughts on that?
I'm honestly liking Minimal APIs more and more. My controller endpoints are simple always, since I often use MediatR. Minimal APIs make this process even easier.
I'm fine with doing 1 action but what if I need to call more than 1 action like CreateInvoice + UpdateUserPayment + UpdateHistory? Do you need to create new handler to combine all these 3 actions or call mediator.Send() thrice with these 3 handlers in api endpoint?
You can either send 3 commands, or raise events after each command completes and process it later.
Thanks for the great content Milan. Have you used the FastEndpoints nuget package? I think it's a great alternative for structuring minimal apis, comes with a nice collection of features out of the box, definitely worth checking out if you haven't before.
I haven't tried it, but I took a look at the documentation. I didn't like the additional ceremony required to define endpoints.
Nice video. I have a small question, Why do we need the 'this' keyword before the IEndpointRouteBuilder?
That's how you define an extension method on the IEndpointRouteBuilder interface.
@@MilanJovanovicTech Thanks !!
what's the diference between carter and just using controllers?
Minimal APIs
Does it make sense to rely on a 3rd party library like Carter to achieve a (in my opinion) rather trivial task like registering the routes automatically?
Assuming we have an API with 100 endpoints that are divided in modules of 5 endpoints each, this would mean adding 20 lines of code to Program.cs to add the endpoints.
Or is the fact that Carter allows you to add things like authorization, cors, rate limiting, etc. the real benefit of this library?
I've used carter for this, or a simpler implementation: www.milanjovanovic.tech/blog/automatically-register-minimal-apis-in-aspnetcore
If a cms thats Modular Monolith use
Minimal API Endpoints will that help increase application speed, performance, lower latency or is it mainly to prevent the spaghetti code?
Minimal APIs are more performant than controllers
Thank you
Hi, in the carter module. How do you add the logging? Please help! I can't DI logger.
Why not?
@@MilanJovanovicTech I sort of figured it out.
i need to use "this" keyword in order to DI the logger.
Instead of _logger = logger it needs to be this._logger = logger.
I cant seem to find the CarterModule. I installed Carter Library version 6. Great vids btw.
Strange?
Another question please, what are the significant Pros to use minimal APIs instead of Controller APIs ?
There are none - except if you need advanced IFormFile support
@@MilanJovanovicTech Thanks Milan
i ended up making endpoints folder at the api project, cant resolve the dependency on Presentation layer bcause not reference assembly something something
That's fine
What's the purpose of the "Presentation" project?
Do I correctly assume that it's meant to keep the "WebApi" project as thin as possible and make the logic of the Presentation project reusable for other WebApis?
You can also merge the API and Presentation as one project
Is there an easy way to use [FromForm] and [FromQuery] with Minimal Apis?
Yes, works the same as [FromBody]
Why "IEndointRouteBuilder" not found in presentation layer?
Is it not?
Great Job!!! Thanks for introducing the Carter Lib. BTW i m interested in howto apply the feature flagging especially using the FeatureGate attribute.
I'll make sure to cover feature flagging soon!
I am using command validators, and after I have tried to add Carter, I was not able to fix DI problems with scoped,... Could you show some example of how to use Carter if your CommandHandle have a CommandHandlerValidator that inherits AbstractValidator
That seems to me like it's completely unrelated to Carter.
Carter only registers your minimal API endpoints, right?
And you register MediatR/FluentValidation separately?
I am trying implement Clean Architecture. I have followed all the instructions from one of the online courses up untill controllers. I wanted to implement minimal API instead of controllers. I did that successfully in the program.cs. And then when I wanted to refactor, problems started. I did successfully by separating in the static classes as you explained at the start of video. Then I wanted to "migrate" to carter solution. At that point "Some services are not able to be constructed"..."Cannot consume scoped service"..." from singleton 'FluentValidation.IValidator'.)" errors appeared, even if my carter modules were empty. Using addCarter and mapCarter was enough to cause those problems.
I am registrating MediatR and Automapper in the ApplicationServiceRegistration
And I am registrating repositories in the Persistence part as AddPersistenceServices.
For Validators I have used AbstractValidator.
I presume it is due to scopes, but I think I have tried almost every combination but without success... Thanks in advance :)
@@MilanJovanovicTech
I feel like I'm the only person that doesn't like the minimal API approach. I get they're more performant, however, I find controllers far more readable. Not to mention they remove the need of something like Carter
The main problem with your attitude: Minimal API is on the hype train. Sooner or later you can't skip it... :D
How is a controller endpoint any different from a minimal API endpoint?
I don't think there's any significant difference.
Me to i don't like minimal api but I used in small project only
I would prefer controller over minimal endpoint.
Just create a controller class that contains your endpoints. I've used MVC APIs for 10 years now and minimal API has been brilliant. No bloat, exactly what I need, if I like controllers then I can still use them (not sure why though). 100% control and everything is visible unlike MVC style with its magic. Just my opinion
How to organize the external API calls in Clean Architecture? It would be nice to see how you deal with…
In the making!
We now have MapGroup feature, so all the advance configuration that Carter provides are not necessary.
Indeed! I do believe that's what Carter uses under the hood
Da li dajes privatne casove za C#
Nažalost ne :)
I would say, Made a full circle back to controllers 🙂
But the performance aspect is different, and some other nuances of Minimal APIs
@@MilanJovanovicTech and minimal apis has limitations even in .net 8
When they came first I thought this is made for micro services.
I thought the minimal API would only be used when your API has less than 10 endpoints and all the Presentation layer can live in Program.cs, I don't see the point of not using the controllers passed that.
They are more performant than controllers. And if your controllers are "thin" you may as well consider using Minimal APIs.
@@MilanJovanovicTech if we add Carter and all on top of minimal API I'm curious if they really stay more performant but quite frankly I don't care that much about performance. If controllers are thin enough I will happily use minimal API or put them all in one controller.
Hi, Do you have source code, in gittube, please, I'd like to exercice! Good, channel, help me to enhance my code. Portugal
I share the source code on my Patreon
I am going to have a lot of endpoints, how about not using minimal api?
The number of endpoints doesn't change between controllers and Minimal APIs
Hello Milan, hope you are well.
you state before that you make a presentation layer as the benefit is just a little stricter control of what you can do in your endpoints.
But inside the Presentation Layer you still can inject for example ApplicationDbContext so i see that you make a control strict on the web api project itself but still can break the clean architecture in the Presentation Layer
I'd say that was just an example, and not the correct way to use it
I do not see the benefit of adding a presentation project and registering api endpoints in it instead of web api project itself.
You're moving away the API definition from the Web projects which has to stich all the service together for DI.
That way, you Presentation layer will only have access to the Application layer commands/queries.
The benefit is just a little stricter control of what you can do in your endpoints.
This works great for small projects but when talking about enterprise level solutions you will need to rethink it.
You will prefer assembly scanning and dynamic loading over stitching everything in the same project as it can it can scale easily, easier to develop and maintain. This is a great way of benefiting of the DI, abstractions and independent modules.
As idea you can get several microservices and just start them from the main process as a monolith, or you can use them independently - when comes about cost the stakeholders will require cheap solutions with the max outcome.
Zero advantages! I'm constantly amazed by how much people like overengineering.
The Presentation folder is the wrong place for the API endpoints. They belong to the Controller side, because they are Input Adapters.
I'd disagree
@@MilanJovanovicTech the point is that your agreement is not necessary. You speak about clean architecture, which has clear Rules about what to place where. There are Input Ports and Output Ports in the Interface adapters layer. And also there are Presenters implementing the Output Ports and Controllers calling the Input Ports. Putting the API endpoints to the Presentation side just confuses, because they belong naturally on the calling side to your use cases / Application. I Like your content but this feels not intuitive.
At first sight, I think it's weird because I'm not familiar with Clean Architecture folder structure. However, it's correct that the API endpoints' mapping code should be in the Presentation layer. The endpoint handlers act similar to Controller methods. Besides, HTTP APIs are not the only way to interact with an API service. WebSocket APIs have their own message handlers too. They can share common logic by calling service classes' methods.
Show less face, and no subtitles word by word.
This video is about tech stuff and not colorful subtitles word by word.
I'm the one deciding that, but thanks for your tip.
@@MilanJovanovicTech yeah of course you decide that, obviously that's not my video lol.