Clean up your .NET Controllers with ApiEndpoints 

Great video as always! Want to note something for those who're struggling with controllers having too many dependencies. There's this useful attribute [FromServices], that will allow you to inject only the required dependencies in your controller method, e.g.: public PicturesController(ILogger logger){ } public IActionResult GetPictures([FromServices] IDatabaseService databaseService){ return Ok(databaseService.GetPictures()); } public IActionResult UploadPicture([FromForm] IFormFile file, [FromServices] IPictureService pictureService){ return Ok(pictureService.Upload(file)); }

I don't see what it delivers except of separation of each method from the one domain controller in each own little controller. Actually it is a lot of duplicate code. Id rather introduce an usecase specific ApplicationService in between the controller- and the server-layer.

Would be great to show how "testable" a new framework is when demoing it. Keep up the good work.

I looked at this ApiEndpoints library and then I thought, well based on the nice isolation of this approach why not just skip both the ApiEndpoints and Mediatr and just have your Controller, Request and Response Dtos in a single folder. Your controller only has one endpoint (Action Result) and only has injected services it uses, and it all looks like you generic controller but you don’t have any dependencies just plain old .net stuff. With this approach I got rid of Mediatr which although pushed things from my controller nicely, I still had one controller with many endpoints (Action Results). You don’t only have to have controller in a web project because its just a nuget package and with custom routing you can keep all customer related endpoints under the same [controller]/[action] style but there all in their own folders following the slice architecture patter quite nicely too. Been working for me for a few months now so quite happy

Damn, I literally stumbled across the repository of this project today and here is your video XD

in the past I used to split controller actions using partial classes which would help a lot merge conflicts and keep things organized. I didn't know about this template, I will give it a try in my next projects. Thanks for sharing

This looks very similar to Azure Functions where you have a class for each azure function that works as a form of 'controller'

What is the overhead on the "override", and in general on this EndPoint mechanism?

Try Cypress instead of Postman ;)

How'd you go about deduping common endpoints? For ex. We have lots of controllers that have a default GET class. This resides in the base class and is used 80% of the time. We call it with a request object which can filter/order/sort/search etc. How would this look for multiple (business/db) entities?

From my point of view libraries like FastEnpoints or ApiEndpoints add way too much boilerplate and external dependencies. I like vertical slicing but you can get this by simply using a single controller for a feature. This is way simpler than using all these nasty libraries.

I assume the Authorized attribute still works

one class for one api call?? with a large project, this would produce hundreds or thousands of classes… why??

We've been using Ardalis Endpoints for a year+ and pretty happy with it. Every method has its own "pipe". It means I don't don't touch the methods whose logic hasn't changed and I can see clear dependencies for each endpoind. It's much better than the controller, which usually has tons of dependencies and it's not easy to understand what depends on what after some time. Thanks for the video, now I'm more confident that we made a right chose.

ApiEndpoints is built on top of mvc controllers, it would be nice to have a comparative with FastEndpoints that is built on top of C# minimal apis

I could maybe misunderstand the problem this project is trying to solve, but if you want to split up your controller to have cleaner code, couldn't you just create partial classes with each their own file name in a folder?

Doesn't seem solving problem. It will require lot of code to be written.

Next video is Services vs MediatR vs ApiEndpoints )

Not convinced, that is more weird. In name of separation increasing code duplicacy and complexity and depending on pray of the third party library.

I'm not sure I understand the point of this. How is this different than just introducing multiple small single-purpose controllers?

So bad. More code, more complexity, less organized and harder to test.

Repetitive and additive code without any benefit. Would be nice to achieve some things with one line, not many.

Open Api is much better for endpoint doc or generating client

On this approach I have so much more to write. By the way you look a little bit tired. maybe you need to see the sun more often 🙂

Well, what can I say, first we make difficulties for ourselves and then we heroically defeat them.

I don't see this package that much more elegant than the current controller architecture out of the box. The only real thing you gain here is a little better code structure.

@Nick Chapsas, thank you for your great content. It would be amazing if you tell us how would this scenario fit in Clean Architecture, in your own perspective. Because it looks like, if we utilize this approach and get rid of so-called "unnecessary" abstractions such as MediatR, CQRS, Repository etc. then we almost would not need Application Layer altogether (aside from definition (Interfaces) of services and DTO Models) since implementation of services done in Infrastructure Layer in Clean Architecture.

What is the advantage of using this instead of dividing a controller up in multiple files using the partial keyword, where you can have one file for Base, Get, GetAll, Update etc?

Ok so basically its one controller per method. Only it's made to look more complicated. I know that it is considered "clean" to have many small files but I really do not like getting into a codebase and there are thousands of files. I really do NOT hope they have started this practice when I come back to work. Terrible! It does not solve any problems it just introduces another abstraction layer for no reason, it does not add security, it does not make the program more modular, it does not make the code more ledgible - in fact it just makes it more annoying to read the code. Somebody thought it was difficult to know which method are using what dependency in a normal controller, well I guess they forgot to just look at the method! Ffs. No, this is useless imo. No offence :) I like this channel.

I wonder what problems this actually solve, if your controllers are too complex and large, the problem is not the controller is it? This is just a different way of wrapping your code in my opinion, more of a preference than a solution to something.

Interesting library, but at the end of the day it all depends on the agreements in the team. Usually What worked for my projects is separating write endpoints to their separate write controller and read controller

I did not like this package too much. Because if I choose to use this way, I will write more code. But I prefer to write less code always. But thanks for your share

What prevents you from creating multiple controllers? you're using the attribute route anyway. You can just create those controllers and just put the action methods you want there.

Which one is better: APIEndpoints or FaatEndpoints?

Wouldn't we end up with too many classes like this

Nick here demonstrating compiler Boostrapping by creating him by him as an example jk. Nice Video Thank you

This is good idea, but in practice this is make complexity in endpoints , I prefer use something simple. "KISS" Thanks

Does it can handle sagger page? if so, how? just installing Swashbuckle as usual?

Despite partial controllers which solve some of issues mentioned in this video, why not creating a separate controller for every action? It needs same amount of work, without dealing with another package.

Thanks for your video, When should we use minimal API and when API Endpoint? Maybe for some situation like versioning or full swagger documentation support that minimal API doesn't support currently, we should use ApiEndpoint. Though?

As I see, the MediarR does the same thing: you only have one dependency in a controller class. What’s the purpose to split up the controller in separate classes, one per endpoint? Or maybe this library is supposed to be an alternative to the MediatR?

Looking at all those classes with the DI makes me want Blazor style [Inject] attributes. I have mixed feelings about so many classes. Maybe it will be easier to parse when C# gets file-scoped classes, but I feel like more files adds more cognitive load than having longer files.

Procedural programming of relational data is obsolete. All of this code can be (and is better) generated from the database model. No need for MVC anymore either.

I encountered a problem: I want to create an abstract endpoint, with some crossing-cutting concerns like getting a userId from the Claims. how can I do this? It seems like inheriting from the EndPointBase is not possible

I've been going more and more in the direction of having a separate handler for each request and this is very cool. The only thing right now which makes me stick with controllers is that I have a two-layered C# application and so I started using Refit to generate the http clients from an interface implemented by the controller. This makes the inter-layer communication a lot more transparent and type-safe. I'm curious if someone has suggestions to have this kind of type-safe strong contract while moving in the direction of separate endpoints like this example or minimal APIs.

this similar mindset with mediator pattern maybe would be very useful when working on a complicated legacy project where you would step by step recreate into an app. again, thanks for sharing

NO! Let us not find the solutions for the problems that do not exist. But other than that, this was really well made explanation of a (not needed) package. Loved watching it.

Since when does `new[]{…}` work in an attribute? O.O

Nowadays you can replace the annotations approach with Ardalis.ApiEndpoints.Swashbuckle nuget and add UseApiEndpoints to your SwaggerGenOptions

Appreciate your efforts. But there is already a lot to cover which is already there with no in depth understanding. Can u pls focus on security features should be followed in asp.net core with angular applications

I searched the meaning of pragmatic and dogmatic while watching this video 😂

Notification gang! Black coffee and Nick sharing generously is a sweet combo

Great video! Was just wondering what font you use ?

Very similar to a serverless approach. Nice I like it

Man, Nick you rock. I will definitely check this out.

Thank you for sharing that with us!

Why not one CustomerEndpoint class and each of the methods its own method in that? I don't get what you really buy with a separate file for each method except to see this layout from the file tree (you could use something like object viewer to see something similar)

Nick, Like then Watch 🙂👍

Nice video! Does your Rider work fine with top level namespaces? Without braces and all of that? Because mine gives Errors

Great , but I think with mediator this way does not bringing any benefit as the mediator will redirect you to the relevant service handler with the relevant dependencies.

Very useful, 👍

What sources do you use to learn all these practices?

Any benchmarks for this library ?

Imagine combining this with CQRS + Services layer + Repository + Unit of Work + Anything else... ohhh too much abstraction. Im not sure if i like the idea of having multiple classes/apiendpoints for every action method. The code navigation would be nightmare. On the other hand having fat controllers with all api endpoints per domain object is a big chaos. So i don't know, i can't say anything. i would like to see this in more advanced scenarios.

What I really like about your videos is that when they are opinionated, you point out that it is opinionated and that there are other ways of doing this that people may prefer. So many RU-vidrs don't do this and it frustrates me and leads me to think that they are purposefully biased and misleading.

Notification Squad

I especially liked that type BaseAsyncEndpoint.WithoutRequest.WithResponse. If I understand this correctly, then BseAsyncEndpoint class, probably does not have any attributes or methods but have subclasses such as WithoutRequest which have subclass WithResponse which finally contains code, all parents are probably just names to make code readable. Have to try this sometimes, I'm pretty sure there were many times when i had classes that inherited some base class and all were name SomeBaseClassWithSomething.

Thank you. A Controller can contain only one method and in this way it looks like Endpoint. :)

Nice approach! I had pretty same feelings about using MediatR instead of the classic application services - you can separate responsibilities even cleaner and simpler.

One of our customers use this, I heavily dislike it tho, this approach has the downside of terrible long names for clases and file names, additionally this approach makes development slower and makes it more expensive for the customers

So this is just another way of doing CQRS?

You and Steve are probably my favorite .NET content creators/instructors. I've learned so much from both of you over the past few years. Great work, both of you!