The Magical Pattern to Organize .NET Minimal APIs

minimal apis are not just for demos also they don't need to be a disorganized mess what if I told you that there's a pattern that can make your minimal apis clean and organized not only that but it also can improve your API controllers so stay till the end if you want to see how the pattern is our epr requests and points response it was first introduced by Steve Smith as a way to organize your controllers but nowadays when you look into minimal apis it makes a lot of sense to apply this pattern since it can solve one of the most common concerns of everyone trying to use minimal apis the lack of structure and organization before we go into minimal apis it's important to reflect about why this pattern exists what type of problems it was trying to solve on controllers and let's start by the most evident one as you know API controllers come from MVC but when you are building just an API you don't have the V there so there's no views so now your MVC pattern is basically an MC pattern so to me it's clear that this solution became the most common one since MVC was the only way of doing things then it started morphing into this new apis approach based on controllers and if this approach is the one that comes out of the box when you create a new project this will conquer 99 of the new projects that you see in the.net space so what's the problem on having those controllers and models alone the problem is that those controllers are not cohesive and when you look into them you can see that they are a collection of methods that you don't see them related to each other each one of those is independent you have your post you have output you have your gets but they don't call each other they don't have a dependency between each other and it's extremely rare to see them working on the same state so that leads to the question is this maintainable is this easy to understand are we respecting the single responsibility visible that's where this pattern can help you let's create a simple API to explain you how to organize using this pattern and what you can gain with it I will not be using Frameworks on this example but by the end I will point you to two that maybe might be useful to you and by the way you can grab the source code as a patron as always let's create a few endpoints to work on top of something like tutus let's have an end point four to the list and another one to create one the same approach that you will be doing on this one you could apply to the rest of your endpoint the first thing that I will be doing is create a folder that will represent this scope of features that I have by the way we will be organizing this in a feature driven way so it's quite useful to take with principles to every single thing you do to this folder and inside the to those folder I will create another one for the list endpoint it's the first one that you'll be creating we have VR hour to those and the list inside of the list folder let's create our first class the class will be our endpoint home let's say since I'm working with minimal apis I will create this class as a static class just to simplify the source code that I will be building in then I will add a method I will invoke this method to register the end points so here I will say that I want to map a get on the API slash to do's and will invoke the endless sync method that I will create now with this we have our first endpoint now it's the time to move forward and make it to something so we'll start returning data and receiving data the return is basically the response what this design pattern tell you is that you should keep your endpoint requests and response together so inside of the same folder the list folder what we'll be doing is to create a new class I will name it response and I will create it as a record why as a record because I find that records are quite useful for this type of things where you have the contract with the outside when we are just transferring data and our response can be something like this for example a film where we'll return saying the total number of to-do's that we have so if you want to do position you can do it for example and also a list of all the data that we are returning on that list and each entry is a response item that will have an ID and a title now it can go back to our endpoints and we Define here the type of the response since this one is just a list will not receive anything we could be getting for example filters or sorting but on this simple example I will not be doing that I will just return some dummy data on this case I will just return something as simple as this let's now take a look into one a bit more complex that is the create the idea is the same create a folder create inside of to-do so if you go through the namespace you know what this thing is about so todos.create dot endpoint on this case if you prefer you can also name for example in this case create endpoint or a list endpoint if you don't want to have multiple things named endpoint inside of your source code do that to the endpoints to the response to the request so every single of those things let's apply the same logic that we have done on the list this time it will be a post and on our endometer now we need to receive something let's create a request record it will be inside of the to-doos.create once again and now we define the properties that that request will have and let's say that to create a new to do I just need to send the title and eventually a due date so I will just Define those two properties so I would use this request to do something and then I want to return something back when you send something to create often you need to return things like IDs you may want to return something like hover or other properties that are calculated by your system so let's create our response object for our create endpoint and our response can be something like this ID title due date and author so now we will send this request to a given service we'll call a database something like that and from that we will eventually get our ID maybe can be another generated ID it can be something that comes from the database whatever we'll return the title due date something more and also the author that obviously would come from authentication for the user identity if we take a look now into the forward structure you can see that now it's quite simple to understand where things are if you are working on the create of a to-do you will get into the end point and if you want to do some changes or you want to access the contracts related to that endpoint they are right there next to the endpoint itself besides that organizing endpoints for different resources will be just a folder side by side with this to those one so if you have any points for different things like managing the users of your system you have a different folder the users and inside there you will have your endpoints to list to get to create something to inactivate to our 5 all the operations will be there as you can see what you get from applying this design pattern is that you will gain maintainability and organization so minimal apis don't need to have that lack of structure that many believe and you also gain a better segregation of responsibilities because now if you need to do something related to the create you have every single thing inside of a single file and you don't need to change the listing point because you are doing a change on the grid for example not only that but in terms of productivity it's quite simple to find related things when you are doing something like MVC you will have for example a folder with your controllers and another one with your models so things related are kept apart from each other this is a feature driven way of structuring your API if you are familiar with clean architecture you may recognize this as a screaming architecture so now the last thing that you'll need to do is to go into your program.cs and we'll call the mappers to map the points in your API and as I promised you let me tell you about two Frameworks that you may want to take a look into so the first one is that if you are currently working with MVC controllers and you want to move into a structure like this one but you don't want to go right into minimal apis maybe you want to see this project it's the API endpoints project by Steve Smith and it can help you to achieve something like the things that I showed you right here on the other hand if you want to start working with minimal apis and you are just starting or you want to apply an organization like this one but you don't want to do every single thing by hand maybe you want to take a look into fast end points fast end points is designed in a way that enables you to apply this design pattern so it will guide you to apply these Concepts so what do you think about this how have you been structuring your minimal apis do you have another approach that I don't know please leave a comment I would love to hear from you and by the way if you are moving from controllers to minimum API case maybe you want to take a look into this video right here I will see you soon in the meanwhile keep it simple

Channel: Gui Ferreira

Views: 7,554

Keywords: .net minimal apis, asp.net minimal api, asp.net minimal apis, dotnet minimal apis, how to organize .net minimal api, how to organize dotnet minimal api, how to structure .net minimal api, how to structure dotnet minimal api, minimal api, minimal api c#, minimal api dotnet 6, minimal apis, minimal apis .net 6, minimal apis c#, organize asp.net minimal api, organize asp.net mvc controllers, organize minimal api, repr design pattern, request-endpoint-response pattern

Id: GZccRBkpc_E

Length: 9min 6sec (546 seconds)

Published: Tue May 16 2023