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.

@Dustyy01

13 күн бұрын

you can do the same with minimal apis

@megachill

10 күн бұрын

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.

@ruslan_yefimov

9 күн бұрын

@@megachill Getting code to production is what brings you money - not shiny code that uses all the js frameworks released last week :)

I'm all for alternatives, but I much prefer minimal APIs in this case. Much less ceremony to achieve basically the same thing.

@flibbertigibbet6324

10 күн бұрын

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.

@shoooozzzz

9 күн бұрын

@@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.

@shoooozzzz

9 күн бұрын

Not to mention minimal APIs are more universally adopted and you don't have to worry about continued support in 5 years from now.

Next episode: "Forget .NET!"

@nickchapsas

13 күн бұрын

Next episode: Forget!

@wertzui01

13 күн бұрын

Next episode:

@winchester2581

13 күн бұрын

@@nickchapsas And Fire

@jamesterwilliger3176

13 күн бұрын

​@@nickchapsasnew platform, who dis

@StaniSoft

13 күн бұрын

Next

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 :)

@obaku1980

13 күн бұрын

i think the same as you

@cew182

13 күн бұрын

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.

@aj0413_

12 күн бұрын

@@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

@aj0413_

12 күн бұрын

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

@Luismvm90

12 күн бұрын

@@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 :)

It feels like mediatR with mapped routes

@LucasHoezee

13 күн бұрын

This was exactly why I came to the comment section to see if anybody else said that.

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.

@mbradea

12 күн бұрын

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.

@duznt-xizt

12 күн бұрын

@@mbradea I smell bullshit 🤣

@damiandziedzic7198

12 күн бұрын

@@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.

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

@davestorm6718

12 күн бұрын

I just began working on my pico-API project. You can chain everything into one line. :)

@bobiyo32

12 күн бұрын

Exactly! I’m still struggling to justify even minimal Api over controllers, those talking about performance are not doing serious work, it is negligeable

@SayWhaaaaaaaaaaaaaaaaaaaaaaat

11 күн бұрын

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 :)

@JosifovGjorgi

11 күн бұрын

it will stop when we get to the point of 1 atom per file

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.

@Bliss467

11 күн бұрын

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.

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.

@unexpectedkAs

11 күн бұрын

Can't you just place your controller, repo, dtos, etc in the same folder to achieve the same?

Been using them a while and they rock. Had a few minor issues but most have been fixed. 10/10

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.

@Denominus

13 күн бұрын

Exactly, it really doesn’t need to be any more complicated than this. I sometimes think people have forgotten how to code.

@baranacikgoz

13 күн бұрын

Yep thats what I do

I posted before but forgot to thanks Nick for publishing interesting content here. Thank you, Nick!

Nah.... still be using dem nice minimal APIs. They seem less hackish to me.

@maskettaman1488

13 күн бұрын

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

@satyayuga0

13 күн бұрын

@@maskettaman1488 to me they don't seem hackish

@Paul-uo9sv

13 күн бұрын

@@maskettaman1488 yeah exactly Forget this new NOISE

@metaltyphoon

13 күн бұрын

@@maskettaman1488lol controllers r hackish. “Hey look! Let’s use a concept related to UI to drive an API! Where’s my View???”

@weifengmao

13 күн бұрын

​​@@maskettaman1488minimal api is functional programming. It's different than controller which is closer to oop.

Been using it since you showed it... very simple and effective!

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.

@emfi8744

11 күн бұрын

Mediahahahah

I have been loving fast-endpoints

All these junior devs in the comments who never got a chance to use Nancy, smh.

I like it, it's a good alternative to what I'm doing with Carter and Mediatr

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.

10:37 I love how you use a movie to create that movie!

I also use this, I love this package

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??

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.

@nickchapsas

13 күн бұрын

You don't have to. You can still return IResult, but I like specifying what my API might return in a union way

@_rcs

13 күн бұрын

@@nickchapsas Thanks.

@MegaJoka100

12 күн бұрын

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.

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 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.

@nickchapsas, Can you share your thoughts on why you use Insomnia instead of Postman? I would appreciate the link if you explained it in a video.

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.

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!

What is your opinion of Data Api Builder? Thanks.

Cool topic

Hi Nick. Would like to suggest to create a video on how to edit videos like you do, it would be very helpful for everyone trying to make their own talks in a public :) Probably you can make it as a short course on dometrain, if you want to get paid for it

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

@damiandziedzic7198

12 күн бұрын

You can just use request. Fast endpoints will map query parameters by name

BTW I loved this tip, so much clear than minimal APIs... cool cool man, thanks a lot.

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.

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.

I think you should have pointed out that it's not just an alternative for controllers, it's an alternative for controllers + mediatr

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 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?

Forget Controllers and Minimal Apis and use a whole separate file for each endpoint instead? That's so much boilerplate and hassle. Not buying it.

You kinda get tied to a 3rd party nuget library though. What do you guys think, good or bad??

@bric305

13 күн бұрын

How many projects use stuff like MediatR, XUnit, NUnit, FluentAssertions, etc.. ?

@heiscalledinvinciblenotinv68

13 күн бұрын

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.

@MooseVonStanley

13 күн бұрын

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.

@heiscalledinvinciblenotinv68

13 күн бұрын

​@@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?

@fusedqyou

13 күн бұрын

@@bric305 Notice the difference. Compare those libraries to something that reinvents a perfectly functioning wheel in .NET

Is there a performance tests for this one?

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?

@evancombs5159

13 күн бұрын

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.

@JSullivan1978

12 күн бұрын

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.

@alexandermercer5363

12 күн бұрын

@@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?

@duznt-xizt

12 күн бұрын

​@@alexandermercer5363Are you kidding? My company maintains a 300+ endpoint medical system made solely on Fastendpoints. Best decision we've made.

@kelton5020

12 күн бұрын

@@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.

It would be interesting to see how versioning works with this.

@alexlo5655

13 күн бұрын

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.

@rayhou6402

12 күн бұрын

asp.versioning can also be worked fine with fastendpoints, it is that in my project.

I love minimal api because: 1. It goes in the direction of functional programming, wirh controllers replaced by static methods 2. I separate the logic from the routing: all the routes and their groups are in one place, their handling are static methods somewhere else Why are FastApi better?

Can you still add auth atributes and such?

how about protected routes? (authentication & authorization)

@CapzTube

9 күн бұрын

Handled really well. Read the doc, it's easy.

@mouradaissani8957

9 күн бұрын

@@CapzTube oo wow docs ....ok

All I want to API improvement is simplified auth handling.

@JSullivan1978

13 күн бұрын

It comes with an auth add on. I use it for creating and consuming JWT tokens and it does the job.

@maskettaman1488

13 күн бұрын

@@JSullivan1978 What do you use, if I may ask?

I use this too! Absolutely love this package and the pattern. Its incredible. Anyone that says otherwise lack experience.

@mbradea

12 күн бұрын

I guess you lack the experience to understand what experience means lol

@JSullivan1978

12 күн бұрын

@@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.

One thing does one job so we can separate each method in a separate class.

@evancombs5159

13 күн бұрын

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.

I notice you're using Rider. Have you done a video on this choice? Did you switch from Visual Studio Proper?

@nickchapsas

8 күн бұрын

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

@timur2887

7 күн бұрын

Rdier is cool with features, but laggy

@7th_CAV_Trooper

6 күн бұрын

@@timur2887 in guessing it's the only game in town for the Mac underclass.

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.

@duznt-xizt

10 күн бұрын

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.

@petewarner1077

10 күн бұрын

@@duznt-xizt That's even worse then, if we have to resolve every dependency just to configure the endpoint.

@duznt-xizt

10 күн бұрын

@@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.

@petewarner1077

10 күн бұрын

@@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.

@duznt-xizt

10 күн бұрын

@@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 😊

What about openapi / swagger ui? Does it detect the endpoints and return types? Doubtful

@duznt-xizt

13 күн бұрын

Hell yeah it does!

@JSullivan1978

12 күн бұрын

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.

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

@evancombs5159

13 күн бұрын

What is so bad about a class?

how do you handle api versioning ?

@catalystcorp

12 күн бұрын

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".

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.

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.

I think it is not a good alternative for controllers and minimal APIs. It seems more difficult to work with and of course there are much more functionalities like Authorize attribute, rate limiter attribute and etc which every one needs to learn how to deal these things with this new approach.

You should start having title like Breaking News😂

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.

@kabal911

13 күн бұрын

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 👍

@alexlo5655

13 күн бұрын

@@kabal911 swagger is about to gone kzread.info/dash/bejne/aqx5zbimoc_YZKw.html

@CabbageYe

13 күн бұрын

​@@kabal911Don't tell me you compared a multi-billion dollar company to a single developer who doesn't get paid for this library 💀

@kabal911

13 күн бұрын

@@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”

@evancombs5159

13 күн бұрын

You cross that road when you get to that road. Until then you don't reinvent the wheel.

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

@nickchapsas

13 күн бұрын

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

@baranacikgoz

13 күн бұрын

@@nickchapsas yep its non related with fast endpoints I just wanted to point out a practice of my 😂

What controllers?

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.

Leaving out the FluentValidation dependency would've made this viable.

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.

I like it

I am fine with minimal api and MapGet MapPost. Doesn't gives any added benefits

So, basically it's a Mediator containing Http Routes.

are they trying to lure developers away from using wcf?

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.

@nickchapsas

13 күн бұрын

Do you have a usecase for AOT?

@pavfrang

13 күн бұрын

@@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.

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?

@junior.santana

12 күн бұрын

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

@sunefred

12 күн бұрын

@@junior.santana Thanks bud!

The API implies I can send multiple responses. If I can't then that's a bad API.

@JSullivan1978

13 күн бұрын

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.

Idk… it seems a lot of boilerplate.

yeh. controllers but fancy

I kinda like minimal APIs, but thanks for the info.

Explanation to all your videos can be little better Nd deeper. Thanks

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.

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 class for one type of request is too much... For functions? Sure. But single responsibility principle shouldn't be class-wise imo.

it feels quirky though

I would stick to minimal api...

No thanks.

Seems like a lot of invented faff for little actual benefit.

Eh. Looks like controllers, but with one method and some nice-to-haves.

I don't get it: why fast endpoints are better than controllers or minimal apis? Just one more method to do same things, imo

@duznt-xizt

6 күн бұрын

Google "Fast Endpoints Brad Jolicoeur". There's an article which explains a lot which this video doesn't.

Yeah, not seeing the point of setting things up this way

Minimal apis to hackish. Feels like nodejs

I prefere minimal api.

May be fast by runtime, seems not fast when it comes to coding.

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.

As an alternative why not GraphQL (HotChocolate) ?

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?

Its the new, shiny thing. Wohooo

@nickchapsas

13 күн бұрын

It's been around for year

@DanWalshTV

13 күн бұрын

Not new. It's been in a stable release for 3 years and has a decent community around it.

@naughtiousmaximus7853

13 күн бұрын

@@DanWalshTV and yet you shouldnt recommend this to anyone trying to work professionally with this technology, especially juniors. Controllers in any remotely large company are the norm.

@evancombs5159

13 күн бұрын

@@naughtiousmaximus7853 what did those companies do before controllers existed? Norms change we shouldn't do something just because it is the norm, we should be willing to grow and adapt to better ways of doing things.

@naughtiousmaximus7853

13 күн бұрын

@@evancombs5159 Thats cool but it isnt how world operates in 90% of cases.

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 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.

Nah. Fast endpoints is bloatware. I wrote a similar thing for my own usage and it's significally faster. Not worth it.

@nickchapsas

13 күн бұрын

🧢🧢🧢

@guiorgy

13 күн бұрын

You can always create something that works in your specific use case extremly well. The problem is making it generic and extensible, and maintaining it. Also, @@nickchapsas What does that mean?

@AKA-077

13 күн бұрын

@@guiorgy he meant it's cap(lie)

@tylercornett2022

13 күн бұрын

Servicestack APIs are insanely better thought out than this, IMHO.

@fusedqyou

13 күн бұрын

@@nickchapsas How about measure actual performance? That seems pretty relevant when making a video on seemingly something that definitely won't be faster?

Too much files

IDK you lost me. I guess I'm just not backend enough anymore. I liked the look of insomnia so I grabbed it to check it out. It turns out they forced their entire user base to switch to cloud storage or be forced to work with the "scratch pad" which is basically garbage. I got nothing but a headache from this video.

@Kitulous

10 күн бұрын

postman will still have your back

Way too complicated, all we need is a method with parameter than can return a response

@duznt-xizt

12 күн бұрын

LoL, there's a reason why the REPR pattern is superior. Time to re-educate mate 😋

«hellovrybody im naked…»