Hi Tim, I love your comments about design patterns. I've been involved in software development for over 25 years and I've seen a lot of code bases. The single biggest issue by far in almost all bad code bases (with no close second) is the overuse of design patterns. Most of the time, code that is heavy with design patterns is nearly impossible to maintain, hard to read,, brittle etc. It is sad that design patterns are still pushed as much as they are, especially when there are often much simpler and robust alternatives. I appreciate you cautionary view, which is, for the most part, sorely missing in our community.
@@Aaron.Aguilar I went with Controllers! Minimal APIs are nice for smaller projects, but for a larger project, controllers feel more maintaintable to me. Probably helps that they're familiar though.
I think the real answer here is like what Tim said "it depends on your situation". I think my time in this space has taught me that most people try and denote solutions as "go to" or "old". I think a similar issue has spawned in the API space where developers who are trying to be cutting edge have heard that "Minimal APIs are the go to" and wont even consider looking at controller derived solutions. I think you just need to consider what is best for your solution. Need a micro service or simple API? great use a minimal solution and spin something up really quick. Need something with a little more control? Awesome then spin up a controller based solution and add some unit tests. I think if you can justify your decision, and it makes sense in terms of the business case, both solutions are equally as worthy. I just always try to not consider anything to be black or white, but what is going to work for me/my team.
I mostly agree with the "it depends", although I've fully moved over to minimal APIs over controller-based APIs now. I don't see the need for controllers and they add a layer of complexity that doesn't seem to be needed. You can do everything you need in a minimal API, including testing, separation of concerns, decorating, and more, but it is in a simpler format with less unnecessary ceremony.
Not sure if you already have a video but I'd like to see a "Should I use Razor Pages or MVC Controller/Views) video. I personally thought you can use both and to use Razor Pages for page-based scenarios but anything too complex then use or refactor to MVC controller/views. I see a lot of people saying "so glad I changed to Razor Pages and I've never looked back" and "MVC is dead" and I don't understand this. I've seen projects with a large collection of actions on 1 MVC controller. The view may have a lot of forms embedded on it with an action for each Post request that accepts all different Form Input Models, or the controller returns several different views and may, or may not, share the same view model (usually not a good idea to share view models but maybe there's a technical constraint). In this scenario, Razor Pages sounds like the wrong tool.
The situation you are describing sounds like an abuse of MVC. Controllers with lots of actions tend to be really messy and hard to maintain. MVC was developed in a time when the only option for C# on the web was WebForms. MVC provided a more structured, testable, modular approach to web development. It became really popular because of that. Now, we have lots of options for development. Razor Pages works well for single pages (index, error, about us, etc.) where there isn't a lot of interaction. MVC can do more complex code separation for larger server-side sites. We used to use it to provide data to client-side applications such as React, but that's not really the best solution anymore. Now we just use API for that. Server-side in general has fallen out of favor because people want rich, client-side interactivity. That's why we now have Blazor Server and Blazor WebAssembly. Two options to give us that client-side interaction while still using C#.
I ran tests and also found that minimal API's are faster than MVC as you don't automatically get all the middleware (you have to explicitly opt into them). So I use that for bespoke gateway with YARP for rewriting but endpoint when I need extra logic but then back end services still use MVC as they are more complex and benifit form the structure
thank you a lot for the explaniation!! I used to use design pattern all the time even if it 's simple project, but after this video I guess I will reduce using it
@IAmTimCorey I would argue against it in large organizations. I believe in templates more than simplicity. This gives the leverage of getting people onboard easily in an agile teams with turnovers.
If you mean the built-in templates, they are almost useless in a large organization. The code of the organization will quickly grow beyond them to the point that the original template had little, if any, impact. In a large organization, it is better to establish coding standards and then apply them to your specific projects. That can include creating your own templates.
I personally prefer breaking features out into modules (for monoliths). So for example, there's a Loyalty Points feature, just create a new folder... A new module. And have a single point of connection to the rest of the code. Then, there, a developer has freedom to choose any code structure they want to apply. Just for all the routes, controllers, service, models or any combination of these which are created within that module. Faster development with the devs coding style innately being used. And easy switching off and on that module. Also, close to zero merge conflicts. . And architecture could be made as simple or as complex as the requirement of the module. . This approach is something I experimented and created for a startup that started out as monolith, but was soon expected to grow to big scales.... And we needed the code seperation for easily breaking it up into a micro service architecture
hi Tim, love your videos, I’m new to programming and I noticed that with Next.js, Blazor “United” and so on, you don’t need an API anymore, is that a trend? Thanks
There is still a need for an API. It is just often hidden. For example, with the new Blazor (they've dropped the "united" word even though it was the best way to describe it), if you use Auto or WebAssembly, you get two projects. One is the front-end project and the other is the back-end project. The back-end acts as an API for the front-end.
@@IAmTimCorey That's my current confusion. With WebAssembly deployment, how does the interaction with a Server Side resources happen if one doesn't also build an API layer over the Data Source and to avoid repeating myself, do I use the API for my Blazor Server components. My hope is that by digging into your latest Blazor course (with .NET8), I'll see how this unlocks. Thanks for the insight on end-points vs. MVC!
@@IAmTimCorey I always get suspect on questions of performance when it comes down to fractional differences with function calls. Unless they are being invoked 1000's of times a second, it rarely matters, but its a honey trap for the ocd tendencies of the coder psyche 😁. 99.99% of the time, performance is impacted by algorithms, i/o and app design.
Hi Mr Corey, Many thanks for your great videos that supports the developer community. Please i was wondering what project template in Visual studio is used for the development of minimal api's.
Microsoft provides the full API project type (with controllers) for both .NET Framework and .NET. They also provide the Minimal API project type for .NET. Finally, an Azure Function can be a very small API (single endpoint). But that's just the project types from Microsoft. Practically every programming language provides a way to create an API. APIs power a lot of the web and mobile applications out there, plus some desktop applications. If you build an API in C#, the best choice for a new project would be either a full API or Minimal API in .NET 6+ As for your question about which ones can be handled by "Microsoft Technology" (I'm assuming you mean a C# application), the answer is any of them. An API is designed to be processed by anyone. That means you can write an API in Java and call it from C#. The same is true in reverse.
Maybe I'm old school, but I'm very hesitant to pick up minimal API's in most scenario's. I do find that the fully structured API's are much easier to read/debug once they hit a certain size, and lets be honest, how many times does a "Small API" turn into a behemoth in industry? Perhaps this is just my experience though, curious if anybody else has experienced anything similar...
Basically... it depends lol :), not disagreeing. A lot of my formative experience predates MVC and I never really got into it. Most of my work is backend services for data processing, which suit minimal apis well. My impression of MVC, is that its best used with User GUI's with a solid focus on standard CRUD.
Do note that Controller-based API have some overhead that Minimal API does not have. For example Minimal API is missing Content Negotiation. As most (if not all) APIs only communicate in JSON this does not have a big impact and otherwise you'll have to add it manually (haven't figured out how to do this. Filters?). So Minimal APIs are faster.
While this is good general advice, I feel like it doesn't address the question in the title. I expected more concrete advice, e.g. "If you need action filters, you should use controllers" (true at the time the video was made).
That list includes: * your team's skills * how well your team can train up in minimal APIs * your existing code * the versioning of the libraries you depend on * the features you need to rely on in C# (more preference than prescriptive) * greenfield or brownfield API * any existing conventions or practices that would weight a choice * your preferences And this is a simpler issue, since both can do similar things.
I think u should never go from controller based structure to minimal API structure. Reason is, codebase will surely get more and more complex even if it's not complex right now. Controllers provide separation of concerns. Now sometimes you may go for minimal API approach especially when you are breaking down monolithic architecture into microservices. But then in case of microservices and API code that won't expand or have more APIs or endpoints for different entities, then go for it. Make minimal API and let it run for years.
How does a controller add more of a separation of concerns compared to an endpoint? I can put endpoints in their own class(es) easily enough. They aren't any more coupled than controllers are.
Hi Tim, I love your comments about design patterns. I've been involved in software development for over 25 years and I've seen a lot of code bases. The single biggest issue by far in almost all bad code bases (with no close second) is the overuse of design patterns. Most of the time, code that is heavy with design patterns is nearly impossible to maintain, hard to read,, brittle etc. It is sad that design patterns are still pushed as much as they are, especially when there are often much simpler and robust alternatives. I appreciate you cautionary view, which is, for the most part, sorely missing in our community.
Thanks for sharing!
Wow I am literally in the middle of making this decision. Fantastic timing!
Great!
What did you chose ?
@@Aaron.Aguilar I went with Controllers! Minimal APIs are nice for smaller projects, but for a larger project, controllers feel more maintaintable to me. Probably helps that they're familiar though.
True creativity requires the discipline to harness the chaos of imagination into the simplicity of brilliance
👍🏻
I think the real answer here is like what Tim said "it depends on your situation". I think my time in this space has taught me that most people try and denote solutions as "go to" or "old". I think a similar issue has spawned in the API space where developers who are trying to be cutting edge have heard that "Minimal APIs are the go to" and wont even consider looking at controller derived solutions. I think you just need to consider what is best for your solution. Need a micro service or simple API? great use a minimal solution and spin something up really quick. Need something with a little more control? Awesome then spin up a controller based solution and add some unit tests. I think if you can justify your decision, and it makes sense in terms of the business case, both solutions are equally as worthy. I just always try to not consider anything to be black or white, but what is going to work for me/my team.
I mostly agree with the "it depends", although I've fully moved over to minimal APIs over controller-based APIs now. I don't see the need for controllers and they add a layer of complexity that doesn't seem to be needed. You can do everything you need in a minimal API, including testing, separation of concerns, decorating, and more, but it is in a simpler format with less unnecessary ceremony.
Not sure if you already have a video but I'd like to see a "Should I use Razor Pages or MVC Controller/Views) video. I personally thought you can use both and to use Razor Pages for page-based scenarios but anything too complex then use or refactor to MVC controller/views.
I see a lot of people saying "so glad I changed to Razor Pages and I've never looked back" and "MVC is dead" and I don't understand this.
I've seen projects with a large collection of actions on 1 MVC controller. The view may have a lot of forms embedded on it with an action for each Post request that accepts all different Form Input Models, or the controller returns several different views and may, or may not, share the same view model (usually not a good idea to share view models but maybe there's a technical constraint). In this scenario, Razor Pages sounds like the wrong tool.
Mvc is a design pattern. You can do MVC on whatever stack you want. It's about segregation of items
The situation you are describing sounds like an abuse of MVC. Controllers with lots of actions tend to be really messy and hard to maintain. MVC was developed in a time when the only option for C# on the web was WebForms. MVC provided a more structured, testable, modular approach to web development. It became really popular because of that. Now, we have lots of options for development. Razor Pages works well for single pages (index, error, about us, etc.) where there isn't a lot of interaction. MVC can do more complex code separation for larger server-side sites. We used to use it to provide data to client-side applications such as React, but that's not really the best solution anymore. Now we just use API for that. Server-side in general has fallen out of favor because people want rich, client-side interactivity. That's why we now have Blazor Server and Blazor WebAssembly. Two options to give us that client-side interaction while still using C#.
Your passion and dedication shine through.
Thanks!
I ran tests and also found that minimal API's are faster than MVC as you don't automatically get all the middleware (you have to explicitly opt into them). So I use that for bespoke gateway with YARP for rewriting but endpoint when I need extra logic but then back end services still use MVC as they are more complex and benifit form the structure
Thanks for sharing!
thank you a lot for the explaniation!! I used to use design pattern all the time even if it 's simple project, but after this video I guess I will reduce using it
I am glad it was helpful.
@IAmTimCorey
I would argue against it in large organizations. I believe in templates more than simplicity. This gives the leverage of getting people onboard easily in an agile teams with turnovers.
If you mean the built-in templates, they are almost useless in a large organization. The code of the organization will quickly grow beyond them to the point that the original template had little, if any, impact. In a large organization, it is better to establish coding standards and then apply them to your specific projects. That can include creating your own templates.
I personally prefer breaking features out into modules (for monoliths). So for example, there's a Loyalty Points feature, just create a new folder... A new module. And have a single point of connection to the rest of the code.
Then, there, a developer has freedom to choose any code structure they want to apply. Just for all the routes, controllers, service, models or any combination of these which are created within that module. Faster development with the devs coding style innately being used. And easy switching off and on that module.
Also, close to zero merge conflicts.
.
And architecture could be made as simple or as complex as the requirement of the module.
.
This approach is something I experimented and created for a startup that started out as monolith, but was soon expected to grow to big scales.... And we needed the code seperation for easily breaking it up into a micro service architecture
hi Tim, love your videos, I’m new to programming and I noticed that with Next.js, Blazor “United” and so on, you don’t need an API anymore, is that a trend? Thanks
There is still a need for an API. It is just often hidden. For example, with the new Blazor (they've dropped the "united" word even though it was the best way to describe it), if you use Auto or WebAssembly, you get two projects. One is the front-end project and the other is the back-end project. The back-end acts as an API for the front-end.
@@IAmTimCorey That's my current confusion. With WebAssembly deployment, how does the interaction with a Server Side resources happen if one doesn't also build an API layer over the Data Source and to avoid repeating myself, do I use the API for my Blazor Server components. My hope is that by digging into your latest Blazor course (with .NET8), I'll see how this unlocks. Thanks for the insight on end-points vs. MVC!
Thanks a lot for the insight, Tim! This clarifies a lot.
You are welcome.
Does minimal api gives better performance vs controller api?
Technically maybe, but it is more preference.
@@IAmTimCorey I always get suspect on questions of performance when it comes down to fractional differences with function calls. Unless they are being invoked 1000's of times a second, it rarely matters, but its a honey trap for the ocd tendencies of the coder psyche 😁.
99.99% of the time, performance is impacted by algorithms, i/o and app design.
You are answer my internal myself question, really thanks 🎉
Excellent!
Controllers really aren't necessary anymore as the minimal API can be built out to be as exactly complex as necessary. They're so good.
They are really great.
Hi Mr Corey, Many thanks for your great videos that supports the developer community. Please i was wondering what project template in Visual studio is used for the development of minimal api's.
How many types of API's exist, and which ones are the modern ones? And which can be handled by Microsoft Technology?
Microsoft provides the full API project type (with controllers) for both .NET Framework and .NET. They also provide the Minimal API project type for .NET. Finally, an Azure Function can be a very small API (single endpoint). But that's just the project types from Microsoft. Practically every programming language provides a way to create an API. APIs power a lot of the web and mobile applications out there, plus some desktop applications. If you build an API in C#, the best choice for a new project would be either a full API or Minimal API in .NET 6+
As for your question about which ones can be handled by "Microsoft Technology" (I'm assuming you mean a C# application), the answer is any of them. An API is designed to be processed by anyone. That means you can write an API in Java and call it from C#. The same is true in reverse.
Maybe I'm old school, but I'm very hesitant to pick up minimal API's in most scenario's. I do find that the fully structured API's are much easier to read/debug once they hit a certain size, and lets be honest, how many times does a "Small API" turn into a behemoth in industry?
Perhaps this is just my experience though, curious if anybody else has experienced anything similar...
Interesting. I haven't found full APIs to be any easier to debug. I've found that it is just a different way to do the same thing.
Basically... it depends lol :), not disagreeing.
A lot of my formative experience predates MVC and I never really got into it. Most of my work is backend services for data processing, which suit minimal apis well. My impression of MVC, is that its best used with User GUI's with a solid focus on standard CRUD.
Thanks for sharing!
Do note that Controller-based API have some overhead that Minimal API does not have. For example Minimal API is missing Content Negotiation. As most (if not all) APIs only communicate in JSON this does not have a big impact and otherwise you'll have to add it manually (haven't figured out how to do this. Filters?). So Minimal APIs are faster.
That difference is negligible, I believe, though.
Thanks for the video. Most videos you keep saying it. Avoid the complexity if it is not necessary.
You are welcome.
How have you not talked about convention vs. configuration? Rhetorical question
Thanks for the suggestion. Please add it to the list on the suggestion site so others can vote on it as well: suggestions.iamtimcorey.com/
Thank you!
You're welcome!
While this is good general advice, I feel like it doesn't address the question in the title. I expected more concrete advice, e.g. "If you need action filters, you should use controllers" (true at the time the video was made).
The problem is that concrete advice on which to choose is almost always wrong. You need to make the right call based upon your specific situation.
@@IAmTimCorey If only someone had advice on which things to take into account, though. /s
That list includes:
* your team's skills
* how well your team can train up in minimal APIs
* your existing code
* the versioning of the libraries you depend on
* the features you need to rely on in C# (more preference than prescriptive)
* greenfield or brownfield API
* any existing conventions or practices that would weight a choice
* your preferences
And this is a simpler issue, since both can do similar things.
Sir ❤❤
👍🏻
For the typical web dev acustomed to piling shit on top of other shit this must sound like heresy.
I think u should never go from controller based structure to minimal API structure. Reason is, codebase will surely get more and more complex even if it's not complex right now. Controllers provide separation of concerns. Now sometimes you may go for minimal API approach especially when you are breaking down monolithic architecture into microservices.
But then in case of microservices and API code that won't expand or have more APIs or endpoints for different entities, then go for it. Make minimal API and let it run for years.
How does a controller add more of a separation of concerns compared to an endpoint? I can put endpoints in their own class(es) easily enough. They aren't any more coupled than controllers are.
AUDIO ASYNC IS SOO HORIBLE IN THIS VIDEO
If you close your eyes, the problem goes away. 😉 Sorry we can’t fix it any other way.