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.
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!
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.
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.
Hey, im using a similar pattern in my current project but I'm having problems using that endpoint in unit tests because the HandleAsync method needs to have all the dependencies which would normally be in the constructor. Do you have any advice for this?
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
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
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
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.
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.
I like this structure, looks obvious and clean. However, you have forgotten to demonstrate how each of these endpoints gets DI dependencies injected: Repositories, Logger, TelemetryClient, DBContext, whatever else real life app needs. And then again, there is never a practical app without Authentication/authorization. You need to show how to apply those in this pattern as well, otherwise this remains just a dead-end concept without practical guidance.
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?
Respect you for large scale of codespace!
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.
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.
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:
ua-cam.com/video/caxS7806es0/v-deo.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.
Hey, im using a similar pattern in my current project but I'm having problems using that endpoint in unit tests because the HandleAsync method needs to have all the dependencies which would normally be in the constructor. Do you have any advice for this?
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. :)
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
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
@@gui.ferreira Then how do we handle dependency injection of ILogger, since it doesn't accept static classes?
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
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.
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%
I like this structure, looks obvious and clean. However, you have forgotten to demonstrate how each of these endpoints gets DI dependencies injected: Repositories, Logger, TelemetryClient, DBContext, whatever else real life app needs. And then again, there is never a practical app without Authentication/authorization. You need to show how to apply those in this pattern as well, otherwise this remains just a dead-end concept without practical guidance.
Another example of making something simple complicated for nothing
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.