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
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
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!
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 😉
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
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 :)
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.
@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.
@@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.
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
Yes, you can apply the Authorize attribute to the endpoint lambda expression. Or you can call the method on the IEndpointRouteBuilder to add authorization
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?
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?
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
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
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?
i ended up making endpoints folder at the api project, cant resolve the dependency on Presentation layer bcause not reference assembly something something
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.
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?
@@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.
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 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.
@@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.
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
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
@@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.
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.
