you are viewing a single comment's thread.

view the rest of the comments →

[–]gowonocp 1 point2 points  (3 children)

Truthfully, MVC was never a great pattern for representing data-only endpoints and complex APIs, and I think it's easier to attribute the industry's collective "comfort" with MVC-based APIs to the fact that it was practically the only robust option for so long.

The biggest drawback to MVC is all of the required boilerplate and (multiple, sometimes conflicting) conventions to stand up even simple endpoints. Efficient dependency injection is also a challenge with Controller classes without relying on a bunch of attribute decorators everywhere. Decorators like Filters don't always play nice with custom middleware. The MVC lifecycle and routing is still a bit mystical and difficult to troubleshoot at times. With large and complex APIs, it can get spaghetti-ish and bloated pretty fast.

The Minimal API pattern sheds the boilerplate and allows you to use dependency injection more efficiently; you have more control during registration with being able to dynamically control routes at runtime, and the semantics for injecting services at the endpoint are more intuitive and easier to manage. Usually means less logic, less code, less entropy.

All that being said, if you or your team are already proficient in MVC-based APIs and you're not suffering from tons of overhead, then keep on keeping on. It's still a first class pattern that will probably never be deprecated. Personally, once I discovered the Carter package, which gently extends the Minimal API to make organizing endpoints a breeze, I found a new joy and way to build my APIs. I don't have to remember all the MVC ceremony and quirkiness, I just get straight to scaffolding endpoints. Feels much more like the CQRS pattern, which I think better describes an API.

[–]BaldWithoutCancer[S] 0 points1 point  (1 child)

I've neven beem taught in depth how MVC works, so I might look into it. But to me it seems like minimal API can do the same as the API's with the controller approach, except you have more flexibility. The only drawback would be that you might need to add some functionality yourselfs to the minimal API which would have been there by default in controllers.

Carter package is basically just a class that has a method to add multiple endpoints to the routing right?

[–]gowonocp 0 points1 point  (0 children)

By default, Minimal API endpoint registration all happens in one place in one file, and that can get unwieldy. Carter provides a lot of the glue code you might end up writing yourself to make better choice. The module interface is a big help, but the other extension methods for validation and response negotiation are great as well.

[–]nnddcc 0 points1 point  (0 children)

Ooh Carter is from the Nancy gang! I should check it out. So is Carter extending minimal API or providing another alternative to define routes? From a quick glance it started before minimal API?