Forget Controllers and Minimal APIs in .NET!
Вставка
- Опубліковано 27 вер 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.
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
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.
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!
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.
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??
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
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 ua-cam.com/video/8xEkVmqlr4I/v-deo.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.
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.
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...
May be fast by runtime, seems not fast when it comes to coding.
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
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.
Too much files
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) ?
Its the new, shiny thing. Wohooo
It's been around for year
Not new. It's been in a stable release for 3 years and has a decent community around it.
@@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.
@@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.
@@evancombs5159 Thats cool but it isnt how world operates in 90% of cases.
Minimal API is still better
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.
postman will still have your back
Too complicated compared to minimal API. Sorry but I'd rather stick with my minimal API 😆
Way too complicated, all we need is a method with parameter than can return a response
LoL, there's a reason why the REPR pattern is superior. Time to re-educate mate 😋
Too much ceremony
Imagine for a product you are building have 100-+ endpoints , too much to segregate even if they are working for same resource. I will prefer using controllers where my SRP can be based on resource and not on endpoints definition.
All the hype from dependency injection, unit testing and fluent have transformed the .NET coding in a very obscure craft. Everything is a black box, injected from somewhere to elsewhere. You don't have control over anything anymore - just use this fluent method that you never heard about and is documented somewhere (if you're lucky) and be happy with it. I don't like it at all. I'm pretty sure I'm getting old and tired of these things, and that's about 50% of my problem with that.
Microsoft moving to fast in bad direction!! Everything is hidden, minimal and so on it's CRAP! You write code and behind the scenes microsoft writes half as much as you! :D
Anyway Controllers aproach is better and more clear. It's dumb to have so many files and everything in so small pieces.
Yeah, don't use this please. Not only does this reinvent a perfectly functioning wheel in .NET, it also complicates the way controllers are written, just to make it "fast". It's not even fast, just "different". If you want fast, write a minimal API, and don't write some complicated mess that takes longer than traditional controllers.
What do you mean by: "It's not even fast"? It's faster than controllers for sure. It's also much more convenient than minimal APIs. What is a "complicated mess" here? It's pretty straightforward
@@davorrilko If it's faster, then benchmark me some results. Apparently this is supposed to be a faster alternative but all I have seen is complications of a system that worked fine. It's a whole lot more work to use this over regular controllers.
Congratulations on reinventing "Controllers" in a complex manner!
There's a significant group of people out there than think making code less organized and structured makes it more complex and therefore more impressive
That looks weird, classic approach is much more useful. Of course, it has some benefits, but force you to write much code, make project structure less observable, and don`t looks good on reading because it`s just some more terrible generics.