The Magical Pattern to Organize .NET Minimal APIs
Vložit
- čas přidán 15. 05. 2023
- How to improve organization and maintainability of .NET Minimal APIs using REPR (Request-Endpoint-Response) Design Pattern.
💎 Be a Patreon to get the source code: / gsferreira
🚨 KEY LINKS
🤝 Support me on Patreon (and get access to source code) here: / gsferreira
👋 HEY FRIEND
If you're new to my Channel, my name is Guilherme, but you can call me Gui if Portuguese pronunciation is not your thing.
I see myself as a Minimalist Software Craftsman. That says a lot of what I talk about here.
So, why this CZcams channel? To share with you to simplify your life as a Developer through knowledge, technology, and practices.
If you are into those things as I do, don't forget to subscribe for new videos.
🔗 GET IN TOUCH
LinkedIn: / gferreira
Twitter: / gsferreira
GitHub: github.com/gsferreira
Visit my blog: gsferreira.com
#dotnet #csharp - Věda a technologie
Hey Gui, thx for the video !
Very efficient pattern, I used it in a project a few month ago with Ardalis endpoints and a blazor wasm front, it gave my team and I a strong and very fast capacity with quick results and obviously lots of clarity.
Amazing feedback Olivier! I'm curious: Did you move to it from MVC or it was a green field project?
Indeed, Gui, you've given an interesting perspective! Similar to software architectures like monoliths and microservices, it's crucial to understand how to leverage each approach based on the problem at hand and the specific scenario. No solution is a silver bullet that fits all cases. Warm regards from Brazil!
Obrigado Leonardo!
100%. "It depends" it's a golden rule of software development.
Respect you for large scale of codespace!
Very nice video. With Minimal API our ecosystem has arrived in the same place as the NodeJs one when it comes to oranizing your project. TBH, i don't think there will be a commonly agreed pattern of structuring minimal APIs in the near future. But what you have described here is a good starting point. However, when you start to build like this real production application you might find that you'll have some things that are common accross different "features". Like endpoint filters for example.Some filters might be global, others might be needed in 30% of your endpoints. Others in 90% of your endpoints. So how would you organize in this case? My working theory that seems to be backed up in practice is a hybrid organization both by features and conventions. In Angular this type of organization is very well documented and a de factor standard.
I agree with you. We are still uncovering ground. Maybe we will learn something from other languages and frameworks.
Regarding your question. From my experience, often those "shared concerns" can either be grouped at a higher "bounded-context" level or they can be handled as an Infrastructure feature. A good example is Logging Middlewares.
Great video. Thanks. When building APIs sharing request-/response models can be powerful. Either in a shared project or a nuget packages. I really like the REPR-pattern and your approach. Is there a way to do both ? I am curious about your thoughts
Having a "contracts" package is an excellent idea. In particular inside an organization with many services.
In that case, I recommend extracting the Request and Response object into the package but follow the same "Feature Folder" driven organization
I think that your handler methods should return Task. Then you can return Results.NotFound() and Results.Ok(result), etc
When you want to reduce the number of folders and files, you can combine the Request, Endpoint, and Response types in a single file.
We can even go to a Vertical Slice kind of approach, like I mention here:
czcams.com/video/caxS7806es0/video.htmlsi=4hNoqPs8WszEbPrh&t=480
Im using similar to this approach except I have all in one file (endpoint, request, response and handler) because in the end this should be small (at least for now they are small and maybe if I see that I get bigger request, responses I guess I will change them to your structure)
I like small and focused files. However, I see the advantage of keeping them together.
I think that the code will tell you once it's the moment to split things apart.
With your endpoints segregated into multiple Endpoints.cs files, how would you effectively group endpoints if you needed to? Inheriting an abstract class for all the endpoint classes (if they were not static) with your endpoint group configurations could work, but would probably obfuscate your endpoint group configurations. How would you solve for that?
In that example I'm using static methods, however, I would possibly review that if the complexity demands it.
Being pragmatic, in that case, likely I would look into Fast Endpoints if the complexity justifies it. I think this Fast Endpoints feature is what you are talking about: fast-endpoints.com/docs/configuration-settings#endpoint-configuration-groups
I built a framework similar to Carter framework which is what I'm using to organize my minimal api
Is it OSS?
@@gui.ferreira Nope. Maybe I'll consider making it an OSS later in the future. :)
though what if you dont want to use controllers (as isnt that the whole idea of minimal web api's, ea short code). The only problem which i face with minimal web api is that they can be hard to find under task main. if you endup having a lot of them.
That's the point of the video. How to structure the minimal API so your API is maintainable and the "main" doesn't become a nightmare.
With all of these static methods how will you use dependency injection?
Oh! I understand. The dependencies are injected into handler methods instead of a constructor. So the class no longer needs to store dependencies that might only be used by a subset of operations. Nice!
That's it. You can find it here: learn.microsoft.com/en-us/aspnet/core/fundamentals/minimal-apis?view=aspnetcore-7.0#parameter-binding-with-dependency-injection
How about versioning?
Excellent question. In this approach, you first group things by domain concepts, however, regarding versioning it depends.
I would group major versions separated at the root level if they are extremely different.
If the API supports minor versioning, an option is to keep those together in the Endpoints.
Many folders instead of combining actions in one class. Minimal API and we end up with more classes than with the classic approach with controllers. But maybe I just have to get used to this...
You can approach it not as granularly as the video is. eg: you could just have a "ToDo" folder and have all endpoints in a single file. However i would keep requests and responses separated. just my 2c
The beauty of Minimal APIs resides in the freedom to arrange them as you prefer.
You can keep a structure like a Controller, where each Action is an Endpoint.
However, I prefer small and specific files and classes with a single responsibility.
@@DieDona 100%
Been here, done that, moved on. Too many files & folders. Does not adhere to the world of micro services.
Your comment is regarding MVC, right?
We gain readability at the expense of way too many folders!!!
I don't see that as a problem.
Another example of making something simple complicated for nothing