Forget Controllers and Minimal APIs in .NET!
HTML-код
- Опубликовано: 26 сен 2024
- Use code GSBLAZOR20 at checkout to get 20% off our new Getting Started with Blazor course: bit.ly/4c9g8YA
Get the source code: mailchi.mp/dom...
Become a Patreon and get special perks: / nickchapsas
Hello, everybody. I'm Nick, and in this video, I will show you how I build very fast APIs in .NET using a library called FastEndpoints!
Workshops: bit.ly/nickwor...
Don't forget to comment, like and subscribe :)
Social Media:
Follow me on GitHub: github.com/Elf...
Follow me on Twitter: / nickchapsas
Connect on LinkedIn: / nick-chapsas
Keep coding merch: keepcoding.shop
#csharp #dotnet
I prefer Controllers with calls to an underlaying service. Keeps all the related routing and URLs for a specific resource or function in one place.
you can do the same with minimal apis
Same here my man. But then again i have been writing APIs since active-x lel so who am i to speak haha. I tend to feel a lot of people get always overly obsessed with any new tech / pattern just because it's shiny, forgetting the business needs and the rest of the team(s) that may need to look at your sh**. I write deletable code and that is way more important than confusing a load of people.
@@megachill Getting code to production is what brings you money - not shiny code that uses all the js frameworks released last week :)
Feels like this is just reinventing the wheel. It's not for me either.
This is the way
Next episode: "Forget .NET!"
Next episode: Forget!
Next episode:
@@nickchapsas And Fire
@@nickchapsasnew platform, who dis
Next
I'm all for alternatives, but I much prefer minimal APIs in this case. Much less ceremony to achieve basically the same thing.
I have found that minimal API + dependency injection leads to bloated method signatures. FastendPoints enhanced with some project specific base classes leads to a happy place between minimal APIs and controllers.
@@flibbertigibbet6324 if you're worried about bloated constructors, use the new Primary Constructors. Otherwise, I don't see how method signatures get bloated because of injection.
Not to mention minimal APIs are more universally adopted and you don't have to worry about continued support in 5 years from now.
@@shoooozzzz This is my only concern. Otherwise, I would choose FastEndpoint every time.
It feels like mediatR with mapped routes
This was exactly why I came to the comment section to see if anybody else said that.
I can see pros and cons, I think Fast Endpoints takes single responsibility principles too far. Minimal APIs sits somewhere in the middle, but I think for now, I would still prefer using Controllers in most settings, even if they perform worse. I think all of these options are about finding a balance between performance, productivity and what fits your team best. It's good that all of these options are available to us, but I would caution against pushing for one or the other as a one size fits all solution :)
i think the same as you
I feel the same way about minimal. There are probably circumstances where they're good for quick implementations. I just don't see them as a replacement for a controller. It's like people just keep jumping to the next thing because it's the next thing and they get bored easily.
@@cew182but they are for Rest APIs? MVC Controllers just has a bunch of stuff that straight up has no value a lot of the time
Just because it works doesn’t mean you shouldn’t migrate to a better tool
Why would you prefer controllers? I just don’t see how they’re not worse when it comes to a an API service than minimal or this
@@aj0413_ I don't know where you got this idea that one is better than the other, but it's flat out incorrect. Not even Microsoft claims that, nor do they push people one way or the other. They provide both options and clearly state it's a matter of picking what works best for you. They don't even have feature parity at the moment, Minimal APIs are still missing features like Model Validation through Data Annotations. Now, we could argue all day if you rather do Data Annotations or FluentValidation, but again it's just a matter of preference.
This idea that fluent language extensions and definitions by extension is somehow more readable than class level definitions or attributes is non-sensical. It gets very verbose, very quickly and when you have to work on a large project with multiple teams, you'll understands how Controllers can keep your code much cleaner and easier to navigate.
Out here in the real world, most businesses don't have the privilege of having 10x developers and all of these new world ways of doing things require a very good understanding of clean code and SOLID principles.
To sum it all up, for smaller projects, smaller code bases and smaller teams, yeah Minimal APIs would probably be my choice... for an actual enterprise level project where you have to deal with churn, upskilling people, multiple levels os seniority and quality... I'll take the more restrictive nature of Controllers any day of the week :)
We have every API built using this library. The product handles 200-300 k users and I loved working with it. I can for sure say this is a solid solution.
Scaling humans is much harder than scaling computers
Optimize for software engineering not low-level hardware
This architecture doesn’t scale up domain knowledge over systems and is only useful in the smallest of projects
It lacks any Cohesive grouping amongst your domain functions (ie: endpoints) and creates a major bloat in your codebase - MUCH more precious than the few milliseconds that I’m sure makes zero difference to your end users.
Optimize for your engineers instead.
@@mbradea I smell bullshit 🤣
@@mbradea It doesn't provide any grouping but It also doesn't prevent you from implementing one. If you feel like your project gets too large group endpoints by folders/namespaces. If you need shared functionality or shared configuration across group of endpoints write abstract base class.
This seems like it has all of the verbosity of Controllers and all of the hackish looking parts of Minimal. Unless this had like a 50% performance boost over them, it's not something I'd use personally.
I agree. I really don’t like inheritance with “hidden” optionally overridden methods that you just have to know exist to override. Controllers handle query and route parameters more elegantly, imo, as arguments to a method.
Nah.... still be using dem nice minimal APIs. They seem less hackish to me.
Minimal APIs are the definition of hacky lol. No reason not to do it properly with controllers if "hackish" is what you want to avoid
@@maskettaman1488 to me they don't seem hackish
@@maskettaman1488 yeah exactly Forget this new NOISE
@@maskettaman1488lol controllers r hackish. “Hey look! Let’s use a concept related to UI to drive an API! Where’s my View???”
@@maskettaman1488minimal api is functional programming. It's different than controller which is closer to oop.
I'm using FastEndpoints in combination with my own code generation scaffolding. Thus, one thing that makes me disagree with a lot of other comments here (i.e., fewer big files vs. lots of small files) is that when I'm using code generation, it tends to work out much better than fewer big files because if I change one endpoint, I only have to regenerate that one thing vs. the whole controller class. Then I can check in only the specific thing that changed, I have better visibility in my Git history, testing is better, rollbacks are better, etc. I like one file per endpoint.
This was good timing. We just started migrating our main API project at work to FastEndpoints as part of our move to vertical slice architecture.
Can't you just place your controller, repo, dtos, etc in the same folder to achieve the same?
I just use a static class with the handler inside per endpoint. Works very well with vertical slicing. Also makes it easy to add specific private extensions such as mapping that are only applicable for that handler.
Exactly, it really doesn’t need to be any more complicated than this. I sometimes think people have forgotten how to code.
Yep thats what I do
I posted before but forgot to thanks Nick for publishing interesting content here. Thank you, Nick!
Been using them a while and they rock. Had a few minor issues but most have been fixed. 10/10
I don't understand the trend now of so much separation. A seperayion that make things even more difficult to track and find. It makes much more sense to me to use a controller that handles all the crud operations. I think next year we will be creating a class to write the endpoint name in, another class to specify the method, another class for the function.then we will end up with hundreds of files instead of 1 class 50 lines controller . And just create a mini project with hundred of classes. I find this to be extreme over complicating simple thing to satisfy the trendy urge of being over organized
I just began working on my pico-API project. You can chain everything into one line. :)
Exactly! I’m still struggling to justify even minimal Api over controllers, those talking about performance are not doing serious work, it is negligeable
because a lot of snowflakes works at microsoft and they love tidy code so they could sleep better and force it on us. This code is MUCH harder to maintain then 1 controller file that have evrything in it :)
it will stop when we get to the point of 1 atom per file
All these junior devs in the comments who never got a chance to use Nancy, smh.
minimal api + mediator. = this. Don't have anything bad to say here, someone had an idea and built it. Respect to that. However if you wanted to sell it as "fast" just spin up a listener yourself.
Rule(s):
Thou cannot undo complexity, you can simply move or hide it.
Design around the axis of volatility.
A metric used to understand if a piece of software is good or bad?
- Does it generally and universally solve for maintainability? if yes then you're progressing and pushing forward, if no you've just built another branch of uncertainty and variance, try again.
Luckily I don't make up the rules.
Mediahahahah
I have been loving fast-endpoints
My biased opinion is that plain old controllers had way more elegant param control than this approach. And since you kind of mentioned that this is faster, it would have been nice to see some comparison between the two (just you like you been doing for tons of other content, which is great).
I have a doubt that this will become very popular, but still - great initiative and kudos for the authors.
Thanks for sharing!
10:37 I love how you use a movie to create that movie!
I also highly use it in my projects. Good thing about it is the opinionated structure. There is no deal to make in the team on how to do stuff, because it is layed out upfront and everyone needs to stick with it.
Been using it since you showed it... very simple and effective!
I am Team Controllers - Minimal APIs feel like they are just that, minimal APIs, that is microservice patterns etc. For other projects I feel it'd clutter Program.cs/extensions too much. Controllers don't, they're much much MUCH cleaner than minimal APIs for any application that does more than 1-2 tiny things. Which is, you know most of real world applications.
FastEndpoints looks nice in a way though - it feels like handler you'd have with MediatR, but without the controller in between.
At 8:48, you should have returned a BadRequest instead of a NotFound. The request being made to the API is invalid, the client asked for a single movie, but didn't specify which one. That is a request that shouldn't have been made, and should not be made again in the future. Hence, a BadRequest. NotFound is for when the client provides a valid id of a movie, but it doesn't exist in the datastore. Such a request is valid, and is allowed to be made again at a later time.
Returning the correct status code is important for good communication. If I receive a BadRequest when calling an API, then I know that I did something wrong, and should fix my problem. When I receive a NotFound, I might not think twice about it, and assume the item is removed for example.
I know this video isn't about status codes, but I wanted to make the remark either way, perhaps it can help someone :)
Nice video as always Nick!
I like it, it's a good alternative to what I'm doing with Carter and Mediatr
I'm not sure you explained it, why do you prefer this? It seems like a lot of extra work compared to controllers, is it just due to speed and minimal apis being too minimal?
He likes it due to how it improves organization of the project. It works on the concept of low coupling high cohesion. By only having one endpoint per class you only inject the dependencies that matter to that specific endpoint. All of the code that is only relevant to that endpoint can all live in the same location (folder or file).
Getting speed benefits by it using minimal APIs as its backing is just the cherry on top. There is an equivalent controllers based project called ApiEndpoints.
Fast End Points nudges you into the Request Endpoint Response patten which, once you overcome the learning curve, produces a much cleaner API since you naturally consider the input, the handlers and the output.
Controllers were designed for MVC. You can make amazing API's with controllers but you are fighting its true nature. MVC nudges you into reusing the input as output, and sharing models across endpoints (does your create endpoint have an unused "id" field because it's also used by the edit endpoint? ) You can of course avoid making a mess and write an amazing controller based API - but the framework is not helping you make good decisions, you're just a good engineer over coming it's shortfalls.
If you took new devs and taught some controllers and some fastendpoints I'm positive the fast endpoints group would write a better api, and write it faster. The only thing going for controllers is familiarity, the large user base and history. It doesn't actually do anything better.
@@JSullivan1978 sounds ok for APIs which have less than a dozen endpoints (in which case I'd argue it's better to just use minimal API instead of unnecessarily adding a package), but you still gonna prefer it when you have an enterprise-level API with hundreds of endpoints?
@@alexandermercer5363Are you kidding? My company maintains a 300+ endpoint medical system made solely on Fastendpoints. Best decision we've made.
@@JSullivan1978 I'm not sure I agree that MVC nudges you to reuse the request model for your response.
I've got an app I'm writing now with probably 50 api calls so far, and I feel like 50+ separate api endpoint files would hurt my brain.
I also use this, I love this package
I use FastEndpoints, but not for everything the endpoints that have a huge number of hits can use it with it but most of the time the regular MVC endpoints are also good.
I love fast endpoints.
Nick, seeing this way to write endpoints, its seems like no need mediatr to separate handlers and request. We can achieve same things with this way to work. What do you think??
You kinda get tied to a 3rd party nuget library though. What do you guys think, good or bad??
How many projects use stuff like MediatR, XUnit, NUnit, FluentAssertions, etc.. ?
you gain some, you lose some. your app has a dependency that may or may not be deprecated and source code is exposed but to have your own code means you have to maintain it.
I've been following this project since the beginning, and while the amount of work that has gone into it is impressive, it's still mostly one individual who isn't getting paid to work on this. It's also different than many packages, it's closer to it's own framework if you go all in.
Given that, I would use it for personal projects, but couldn't recommend it for business facing projects and take the risk of requiring a major rewrite because it has become abandonware.
@@MooseVonStanley i guess in that case it falls to us the community to continue its support (whenever we are in mood of course). i mean isn't it worth it? i don't have much experience as a software engineer but it could be a boon to everybody right?
@@bric305 Notice the difference. Compare those libraries to something that reinvents a perfectly functioning wheel in .NET
I use this too! Absolutely love this package and the pattern. Its incredible. Anyone that says otherwise lack experience.
I guess you lack the experience to understand what experience means lol
@@mbradea Having 10000+ hours with controllers and 500+ with FastEndpoints I can say, for MY use cases that Fast endpoints is better.
For reference I generally build high use (10,000 RPM +) API endpoints.
I think you should have pointed out that it's not just an alternative for controllers, it's an alternative for controllers + mediatr
BTW I loved this tip, so much clear than minimal APIs... cool cool man, thanks a lot.
I like this. The only thing I don't like is having to explicitly specify to response types at 11:00. It feels less flexible than returning an ActionResult from a controller action.
You don't have to. You can still return IResult, but I like specifying what my API might return in a union way
@@nickchapsas Thanks.
It's a not verbose and less flexible, but that single feature is one of the best things in FE imo. Simply because your generated API docs now always correctly reflect the actual possible return types. ActionResult only gives you the 200 OK, and you still need to add a lot of redundant attributes for the remaining possible error types.
What is your opinion of Data Api Builder? Thanks.
I see a lot of people claiming that minimal APIs are more performant than controllers, but I'm yet to see anyone show it with benchmarks and the same goes for FastEndpoints. While I like the idea, How much more performant are they? Does the difference matter?
If you AOT compile, is there still a difference?
how about protected routes? (authentication & authorization)
Handled really well. Read the doc, it's easy.
@@CapzTube oo wow docs ....ok
All I want to API improvement is simplified auth handling.
It comes with an auth add on. I use it for creating and consuming JWT tokens and it does the job.
@@JSullivan1978 What do you use, if I may ask?
Idk… it seems a lot of boilerplate.
It would be interesting to see how versioning works with this.
They have a documentation for this. You also can add a Swagger and Authentication. But if for Controllers and Minimal Api you can find the examples everywhere, but for Fast Endpoints you have to dig up in documentation by yourself.
asp.versioning can also be worked fine with fastendpoints, it is that in my project.
Thanks for the great video Nick! I think there is an issue with how the BadRequest maps out in the return response switch in the CreateMovieEndpoint. The result.Match passes through to the response correctly, however the BadRequest is not caught when validation fails and it causes the "Impossible" Exception. Different types of BadRequest being compared? Any thoughts appreciated.
...and looks like the signature needs to be updated for the Endpoint base class and override to BadRequest. BadRequest on it's own does not seem to kick in. Cheers!
Why store your requests in a contracts folder vs storing them with the vertical? The whole point of this type of architecture is to have each vertical be a source of truth for the feature/aggregate root/etc that it represents. If I have a junior or contractor dev, it's much easier to say "You're editing Movies. Your whole world for this ticket is in this folder. Write code outside of this folder and it fails on the merits". It makes it easier to spin up new devs unfamiliar with the project.
What controllers?
You became too much dependent on the third party libraries. Fast Endpoints, MediatR, Automapper, Swagger, etc. What will be if in some point support for these libraries drops? Or they became not a public source and start charging money for this? Or they became not compatible with the current Microsoft stack? If Automapper I can change by just mapping manually but how you can change Fast Endpoints? It will not be an easy task.
Might as well just create you own programming language, I mean what if Microsoft decides to do all those things 🤷♂️
Best to also use customer resources on building framework and library rather than building their actual product 😊
Not advocating for their specific library though - for me it doesn't solve anything or make existing things better 👍
@@kabal911 swagger is about to gone ruclips.net/video/8xEkVmqlr4I/видео.html
@@kabal911Don't tell me you compared a multi-billion dollar company to a single developer who doesn't get paid for this library 💀
@@CabbageYe nope, I didn't compare anything 🤷♂️
I made a comment as absurd as “don't use 3rd party libraries, just in case you can no longer use them”
You cross that road when you get to that road. Until then you don't reinvent the wheel.
Can i still get the discount code for any courses?
Not a fan of this approach. Actually seems like a lot more work than a standard controller approach which is tried and tested. I'm also not a fan of minimal apis either. Personally I don't like the "javascriptification" of endpoints and for me there is no reason to change to minimal apis given all the heavy program.cs config you have to do to get them to do what controllers do out of the box. Great video as always though and it's always good to see an alternative option even if it's not my cup of tea.
One thing does one job so we can separate each method in a separate class.
We don't necessarily want to separate each method into a separate class, but we do want to separate each endpoint into its own class.
at some point this is just moving the work. You point out its faster to build and faster at runtime... but my personal opinion is that this would be way worse to maintain, and increase ceremony. I realize there are implications to it, but an attribute over a method name is way faster (at dev time). I like minimal api's with the exception they quickly become more difficult than controllers to maintain, and if you are doing anything remotely complex with those endpoints, it ends up being quite a bit MORE code than a controller endpoint.
I'm not convinced you couldn't have the best of multiple worlds.
Not sure how I feel about the endpoint setup occurring in the constructor, and therefore an instance of every endpoint created at startup.
Then again, every delegate used with Minimal API is also an allocation, which is analysed and turned into a RequestDelegate. So if each endpoint in FastEndpoints ultimately provides a RequestDelegate, it has the potential to compete with minimal APIs in performance terms.
I'll take either of these approaches over controllers though.
Last time I checked, the Configure() method is only ever run once. Ctor on the other hand is called per each request which allows me to inject services from the DI container. They have benchmark results on their website you can check.
@@duznt-xizt That's even worse then, if we have to resolve every dependency just to configure the endpoint.
@@petewarner1077 I maintain a medical system monolith with over 300 endpoints and the application starts in about a second. App is only restarted about once a month, so no real impact from cold boot speed. Btw, I'm using their type discovery source generator to avoid the assembly scanning/reflection cost.
@@duznt-xizt No doubt a lot of effort has gone into the performance of it, and I won't rule out using it future if necessary.
I just don't understand why regurgitate an idea that was flawed 10 years go of creating a bunch of instances of classes and all of their dependencies in order to obtain configuration data at startup, and then throw them away.
Annotating with attributes and having code-gen write the registration code would've been the better choice.
@@petewarner1077 I understand where you're coming from, but I personally consider attribute annotations as visual clutter for config. Back when I was using MVC Controllers, I used to have 10-15 lines of attribute decorations on controller methods, which IMHO is horrendous from a code readability perspective. This lib has brought back the joy in writing backend apps for me 😊
You should start having title like Breaking News😂
Is there a performance tests for this one?
i understand advantage of those, but i prefer minimal apis. Big thing i like about minimal api's is it reduces the amount of classes. IF only we had top-level statements not only in the "main" file then they would be even greater
What is so bad about a class?
Leaving out the FluentValidation dependency would've made this viable.
Tbh this seems like a good way to pollute your code base with an entirely unnecessary amount of files. But I also disagree with SOLID principles in a lot of ways so maybe that's just me but I'd absolutely hate working in a code base built on the architecture this approach spawns. Not to mention the difficulty of on boarding people when there's so much hidden magic going on in the background you have to be aware of.
Can you still add auth atributes and such?
Cool topic
Can you do content negotiation?
Easy? Yes.
Productive? Probably.
Maintainable? Barely.
Friendly to new employees? Not even close.
It's an interesting concept and an obvious one (IDK how many times I got annoyed that my constructor received more than the minimal number of services because one action used it) but when your API gets to a certain size this approach will be cumbersome to work with.
Still would have been nice to see some numbers on the performance claims, we've all done ugly code in the pursuit of performance.
What's a slug?
A somewhat friendly unique identifier. In his example it's the name of the movie+year. That can be used in the URL instead of the internal ID for example
@@junior.santana Thanks bud!
I've had problems with FE when I wanted to use classes/endpoints/etc. with a certain name. It just wouldn't register these endpoints. It took me quite a long time to figure out that FE reflection engine filtered anything that contained 'System' in it.
I've tried it before but still prefer the combo of MediatR with MinimalAPI. I can prepare a mediatr command and even pass the command as [AsParameters] in the endpoint mapping (I learned that from you). I can then return ActionResult based on what the mediatr command returned.
Is there a way to get a class from QueryString like controller? For example, [FromQuery] Parameter param?
Last time I checked this lib I couldn't make it work
You can just use request. Fast endpoints will map query parameters by name
I use minimal apis along with repr pattern, this thing does not seemm to add value over minimal apis. And also, I wrote a generic endpoint filter to take result object and return the response using Match. So I dont have to write Match..... in every endpoint. I just return a Result object, the endpoin filter do the rest
You don't need to write Match in every endpoint anyway. That's a thing I am using, it has nothing to do with FastEndpoints
@@nickchapsas yep its non related with fast endpoints I just wanted to point out a practice of my 😂
What about openapi / swagger ui? Does it detect the endpoints and return types? Doubtful
Hell yeah it does!
It has very good NSwag support, with a decent defaults and many extensions for tweaking the output.
When using fastendpoints I find the swagger output is way ahead of API's written with Controllers. Controller based api's normally miss documenting how errors are handled since no one makes this a priority.
The API implies I can send multiple responses. If I can't then that's a bad API.
You can. Out of the box it supports Microsofts "HttpResults" so you can return Typed "Results".
Defind the endpoint like so:
public sealed class Endpoint : Endpoint
Inside the function it's "typed" and you can return any of these results and they map ... and it wont compile if you try to return something else.
I use C# as a client (Blazor) and it understands this endpoint and can also map the results.
My tests also know what they will get ... even swagger understands the possible outputs.
I like it
Million dollar question, can this return XML? :)
It can return whatever you want. Have a look at their "Cook Book" section.
One class for one type of request is too much... For functions? Sure. But single responsibility principle shouldn't be class-wise imo.
So, basically it's a Mediator containing Http Routes.
I am fine with minimal api and MapGet MapPost. Doesn't gives any added benefits
I notice you're using Rider. Have you done a video on this choice? Did you switch from Visual Studio Proper?
I switched from VS in 2019, when Rider became actually usable. I have an old video on the topic but I think I need to remake it
Rdier is cool with features, but laggy
@@timur2887 in guessing it's the only game in town for the Mac underclass.
how do you handle api versioning ?
Does anyone \*actually\* use api versioning? like for realsies, and stick to it? It has to be vanishingly rare.
But anyway you'd just make it a route param: "{apiVersion}/foos/bar".
are they trying to lure developers away from using wcf?
I don't get it: why fast endpoints are better than controllers or minimal apis? Just one more method to do same things, imo
Google "Fast Endpoints Brad Jolicoeur". There's an article which explains a lot which this video doesn't.
I prefer minimal API, at least for simple cases which covers 90% or so. Creating own classes for everything and wire them up is just too much code for such simple tasks.
Explanation to all your videos can be little better Nd deeper. Thanks
Great video for the FastEndpoints!
Unfortunately it uses Reflection and cannot be used in AOT apps.
The comparison in speed should be with its fastest alternative: AOT with minimal APIs, not plain minimal APIs.
Do you have a usecase for AOT?
@@nickchapsas I will prepare a test case and send it. My latest projects are in AOT exclusively. A little pain in the ass due to the lack of FluentValidation (absence of reflection sucks), however, I stay here for performance exclusively.
Seems like a lot of invented faff for little actual benefit.
Nah. Fast endpoints is bloatware. I wrote a similar thing for my own usage and it's significally faster. Not worth it.
🧢🧢🧢
@@guiorgy he meant it's cap(lie)
Servicestack APIs are insanely better thought out than this, IMHO.
@@nickchapsas How about measure actual performance? That seems pretty relevant when making a video on seemingly something that definitely won't be faster?
We aren’t talking about creating a framework here, just adding some structure. Organize your handler functions (they are just functions), map them with extension methods. You don’t need a library or a framework to do this.
Yeah, not seeing the point of setting things up this way
yeh. controllers but fancy
I would stick to minimal api...
Minimal apis to hackish. Feels like nodejs
May be fast by runtime, seems not fast when it comes to coding.
No thanks.
I sometimes get tired of this sentiment. Software development increasingly resembles an infomercial attempting to sell the next big solution for a problem I've already solved. No need for me I will pass.
Eh. Looks like controllers, but with one method and some nice-to-haves.
This situation resembles NancyFX's history. FastEndpoints may face obsolescence as upcoming .NET versions are likely to bridge any remaining gaps with FE. Consequently, it's plausible that FE's maintainers might lose interest and focus their talents on other problems., as is often the case.
11:51 Task … looks very complicated for such an easy task 🤨
I suspect as MinAPIs developed, they'll be on par with Fast API. But since its MS it would then have much wider adoption. Remember Nancy?
it feels quirky though
Usually I create a bunch of endpoints in a single task. They usually belong to one feature. This would absolutely make me less productive.
I don't think this has any real use case anymore.
It might have had before minimal endpoints were a thing. Emphasis on might.
In comparison to minimal endpoints, this seems to take about 10 times as much time, with no discernable upside. And splitting the logic of request and response is not one as that can hella easily be done with minimal endpoints as well, using extensions.
It's a cool package and hats off to the devs, but these days, it just seems to exist to solve problems which are no longer there.
Hmmm… it looks like a lot of code for each and every function of your api. Minimal apis to me are useless for anything more complex than a couple of endpoints. Good old controllers are the sweet spot to me, although definitely not exciting as a newer thing could be.
I prefere minimal api.
So one class per endpoint? Sounds more complicated than Minimal API, even more than MVC. Are FastEndpoints MUCH faster than other options? That would be the only reason I'd give it a look.
Too much files
all world: just uses handler functions, like
`router.Handle("/movies", getMoviesFunc)`
.NET devs: hey let's create 15 classes, DI, method overrides to create 1 handler
You are missing the point my friend 😅
I sometimes worry that monetization is getting in the way of good / accurate suggestions. It's starting to feel like you're being paid to say things. 😢
What are you talking about?
Glad I’m not the only one seeing this.
I also don't love how every video is like, right at the 8 minute monetization mark, even when the video is something that could be demonstrated clearly in like 2min. Just like FastEndpoints, there's a lot of needless bloat going on here in order to hit some marketing metric that's directly hurting the quality of the product.
@@andrewshirley9240 Could you identify exactly what parts you think are bloat?
As an alternative why not GraphQL (HotChocolate) ?