Minimal Apis for me so far. I never liked Controllers honestly because i want vertical structure of my app and controllers are all about horizontal structuring
I get that. I loved controllers when they were first released, mainly because of the MVC pattern overall. I wasn't really building APIs at the time. But yeah, Minimal API would definitely be my choice for something quick and small, but I'm definitely fanboying over FastEndpoints right now for larger projects.
From a code organization standpoint, Controllers can often end up being "dumping grounds" in so much as we tend to align controllers with Entities in the DB, and developers will try and fit in. Ie. WidgetController "well, we need to get a report on the number of widgets sold, let's stick it in the WidgetController". And not to say you can't have the same situation appear with Fast Endpoints, but from the examples I've seen so far, endpoints are based more around the actions with verbiage (I won't go so far as to say restful), so even if a behavior does get misplaced, it's much easier to see and much easier to move.
I agree. As in your example, I often see things like "ReportsController" that have hundreds of endpoints so that people feel better about not putting the method in your example in the WidgetController.
Hey, I love the video, it gives a fast overview over the different options for creating web api endpoints. Also I didn't know about fast endpoints, thanks for explaining that ! However, I would love to touch on something that you didn't quite mention in your video. There is an attribute for the controller based approach that's called "FromServices" using that attribute you can inject dependencies into the individual methods instead of injecting them over the controllers constructor and having the mentioned downside of executing logic to fetch a certain service but not actually needing it. So that is not really an advantage of minimal APIs.
Thanks for the feedback! It's is GREATLY appreciated. And you're absolutely right. You can apply the FromServices attribute to inject a service directly into a controllers method, but (and maybe this is just personal preference) seeing FromServices in controller methods always seemed like code smell to me. Do you use it frequently? Regardless, that's very valid input that I should have probably mentioned.
@@BaldBeardedBuilder Hey man, first of All let me say one thing: After seeing your channel today for the first time I wasn't really sure if I should sub but now you have DEFINETLY gained yourself a new subscriber because you actually took the time to write such a detailed response (if we consider that you get quite a lot of comments) so THANK YOU for that ! Now to answer your question I actually encountered it the first time as a company guideline where I used to work but I've been using it ever since. Because to me it is quite the opposite the "FromServices" let's you know that this is not a Parameter That gets passed in the http request but that it get's loaded out of the DI Container. Additionally if you put the Parameters in the controller under each other so one line for each parameter you have the from services always at the beginning so you see which Parameters are from DI and also of course you should group them together so like all DI params at the end. Then I think it can even help with understanding what is going on at first glance and you get to keep all the Controller benefits that the other two don't have. But of course we are all different and we all have different preferences. But since I started with .Net 15 years ago (which was before the fluent syntax hype as you are surely aware) controllers do have a special place in my heart ❤️
I use Minimal API with static methods, gives me all the same benefits as controller classes, without some of the drawbacks You can in fact use comments with Minimal API, just map a static method rather than a lambda :)
Minimal API doesn't expect the endpoints to be in one class. A good option is to move them into their own file for logical groups and use the group option. Use an interface with a register method to set them all up and then use an extension method to search the assembly for those Interfaces and call the registration method on each. Voila, potentially tens of files with hundreds of endpoints well structured and nicely registered.
It's been a month since I recorded this. Did I say it "expects" them to be in one class? If so, I definitely misspoke. I agree with you and I group them with an extension method to register them, but oddly, that isn't what most Minimal API examples show. Maybe I should do a more in depth look at Minimal API with real-world code to discuss good project structure, better registration, etc. Regardless, thanks for joining in the conversation. Did you know we script, record, edit and discuss all these topics while we co-work together on Twitch? Check out bbb.dev/twitch and help us make better content while we work together.
Love the minimal api approach, I have a large minimal api in development, now I'm wondering if I should checkout FastEndpoints. How difficult would it be to migrate and existing MinimalAPI to FastEndpoints? Fortunately, maintaining client compatibility is not a requirement yet. Reservations: - Don't want to get locked into a 3rd party platform - Client Code generation, we autogenerate C# client libraries from the api swagger spec, can we do this with FP?
Thanks for the feedback! And you're absolutely right. You can apply the FromServices attribute to inject a service directly into a controllers method, but (and maybe this is just personal preference) seeing FromServices in controller methods always seemed like code smell to me. Do you use it frequently? Regardless, that's very valid input that I should have probably mentioned.
@@BaldBeardedBuilder Yes, it is actually my favorite approach. I don't see how it is any more smelly than injecting services into minimal api actions, and I don't even know whats so smelly about it. :) (Injecting dependencies by method parameters is the more functional way of doing it.) Yes, controllers lump together methods that don't relate too much too each other, but you should not look at controllers as objects in the object oriented sense. Look at them more like modules, a collection of functions more or less. With bigger minimal apis, you'd still want to organize your actions some way, and controllers already solve that problem, and bring a few bonuses with them (shared root route, openapi support etc). :)
That's interesting. In the end, it's likely personal preference. I think the "smelly" thing to me, and again, this is just my personal preference, is you don't normally learn to do injection with controllers via FromServices. It's an attempt to make controllers more functional, like Minimal API. While you CAN do it, it's not the normal pattern taught & used. Whereas in Minimal API it is THE pattern. Shared root routes are done in Minimal API with groups, but I 100% agree that OpenAPI support is much nicer with the Controller approach. Super good conversation though. You might want to join our discord at bbb.dev/discord where we talk about this nerdy stuff all the time. It's always great to learn & build together!
Where I work we use MVC controllers and MediatR (along with fluent validator and other middleware). If I was to do another app I would switch to minimal API and MediatR, or checkout fast endpoints as it sounds very similar.
Shocked face thumbnail? Does it still work? I thought we were quite past that phase. Maybe it’s time to try something new. Like stick your tongue out or pick nose booger to rope in viewers.
Believe me, there is nothing more dehumanizing than taking those photos. However, after testing a dozen thumbnails, this still does best. I hate it. But hey, if you think the booger-picking would add value, I'm game. 🤣
Okay, I could have worded that better. Perhaps saying they live in "a" class rather than "one" class, but the point was minimal API routes live in a class, where FastEndpoint routes are the class. Keep those nits coming. 😁
