Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Minimal APIs at a glance in .NET 6

hanselman.com

Post reply on HN
Print view View original

71–80 of 114 posts

Re: Minimal APIs at a glance in .NET 6

#71

Post by giobox »

corpdronejuly wrote: post #48
oaiey wrote: post #23

This is part of a larger push to make ASP.NET Core and .NET easier for beginners. The difference between node.js + express vs. ASP.NET Core was a lot of boilerplate to return the first Hello World. Overcoming that churn is a huge problem for .NET adoption. Do not take three-line-minimal APIs as the end product for robust, safe and reliable endpoints. We all know better than trusting 3-line-presentations. As a seasone…

The bigger issue for me will be the way that these kinds of things tend to split communities. It doesn't do big enterprise devs much good if we have a lot of cool new features if there's no path towards using them in our 20 year old legacy applications that keep the business running.

If you are a server side web app, the migration process from legacy net Framework app to net 5/6 has gotten _a lot_ easier in past few years.

The biggest barrier for most in my experience has been getting through the project file (*.csproj) changes needed. Even today, there is still no fully automated way to do it. Thankfully, after ~4 years of community complaints, Microsoft finally aquiessed and made a CLI tool that does about 80 percent of that work:

https://github.com/dotnet/upgrade-assistant

Before the release of this tool, you had to rely on community made tools/guides or just rewrite the project file by hand to the new format. I inherited a project with over 600 large net4x csproj files - prior to this tool Microsoft's official stance was "rewrite them by hand". This goes down like a cup of cold sick at many Enterprise software shops with hundreds or thousands of project files to update.

I still think the upgrade process needs some more polish/wizards in the VS UI, for junior developers especially, but it's gotten much better. The vast majority of important third party dependencies are all net5 ready now in my experience now, so often just replacing the csproj file and setting target framework to net5 is enough.

If you have a legacy WinForms/GUI app however and want full cross-platform benefits of net5... cost to move to modern UI framework can be significant. CLI apps/web apps are by far the easiest to port to net5.

Re: Minimal APIs at a glance in .NET 6

#72

Post by achtung82 »

magicalhippo wrote: post #49
jameshart wrote: post #19

It never takes long when throwing together toy examples with these kinds of APIs to introduce a security risk: var uploads = Path.Combine(uploadsPath, file.FileName); Where file.FileName appears to be drawn from the content-disposition header of the request. MS’s own asp.net docs on file uploads say: “Use a safe file name determined by the app. Don't use a file name provided by the user or the untrusted file name of…

> At least when the controllers are all classes I can unit test them. So I've literally just jumped into this world, having never touched asp.net or similar before. I looked into how to test the controller side of things, and came across this[1] post arguing that unit testing controllers weren't as useful as integration testing them. Integration testing would definitely be useful, and something I will do, but I assum…

Integration testing as im used to it takes less time to write than unittests since you need to spend less time mocking things (mainly just mock external requests). Of course the initial setup requires more time but there are many readymade examples you can copy from. For example the official documentation.

https://docs.microsoft.com/en-us/aspnet/core/test/integratio...

Re: Minimal APIs at a glance in .NET 6

#73

Post by GordonS »

jeswin wrote: post #15
ddek wrote: post #2

So I guess we've had 'JavaScript but like C#', in the form of TypeScript; so I suppose now we get 'C# like JavaScript'? I must admit, I find this amusing. I suppose this raises two questions: "Why use C# like this in place of express or koa on node, which idiomatically similar?", and "Why use C# like this instead of C# like that (the way all other AspNetCore apps do it)?"

1. The web server component could be fronting a middle-tier written in C#. There are numerous advantages to doing this in .Net over Node. 2. Performance. 3. Native AOT is coming in 6.0. Meaning, you get a native platform specific app which can run without the framework - like golang. But with GC, so not like C/C++/Rust.

I've been using C# since it was released, and I'm a huge fan.

But I can almost guarantee that native AOT doesn't appear with dotnet 6 - they've been promising it for several years, and it's become Microsoft's Duke Nukem Forever,

Re: Minimal APIs at a glance in .NET 6

#74

Post by SketchySeaBeast »

kumarvvr wrote: post #32
andix wrote: post #8

The old convention based model for controllers, was really difficult to understand and debug. You never knew what routes exactly were discovered by reflection. It was just too much magic, and too many conventions. I hope this will make it easier. Reminds me of the good old Nancy times.

More importantly, if the default is to depend heavily on conventions, MS should have had a big glaring button / warning / notification in the Introduction page, which summarizes all the conventions used. Would have saved many beginners a lot of time. I am an experienced programmer and was very frustrated having to search for all the conventions used in the framework.

Absolutely. I've wasted hours doing things that, if I'd been shown the way Microsoft wanted me to do them, I'd solve in 10 minutes, but instead I need to spend a ton of time trying to figure out why the new variable on my model isn't binding correctly because I didn't realize they need to be properties.

Re: Minimal APIs at a glance in .NET 6

#75

Post by stonemetal12 »

magicalhippo wrote: post #49
jameshart wrote: post #19

It never takes long when throwing together toy examples with these kinds of APIs to introduce a security risk: var uploads = Path.Combine(uploadsPath, file.FileName); Where file.FileName appears to be drawn from the content-disposition header of the request. MS’s own asp.net docs on file uploads say: “Use a safe file name determined by the app. Don't use a file name provided by the user or the untrusted file name of…

> At least when the controllers are all classes I can unit test them. So I've literally just jumped into this world, having never touched asp.net or similar before. I looked into how to test the controller side of things, and came across this[1] post arguing that unit testing controllers weren't as useful as integration testing them. Integration testing would definitely be useful, and something I will do, but I assum…

Unit tests are valuable if you are doing some sort of "computation". If all code in question is doing is plugging x into y, then unit tests are useless and integration tests are where the payoff is.

If you have code that does both plug and compute you should refactor them so that computing and plugging don't happen in the same place. Doing so will reduce instances of hard to test code.

In general controllers are plugging code not computing code, so integration tests tend to be the more appropriate choice.

Re: Minimal APIs at a glance in .NET 6

#76

Post by Rapzid »

andix wrote: post #42
kumarvvr wrote: post #32

Earlier quoted context omitted.

More importantly, if the default is to depend heavily on conventions, MS should have had a big glaring button / warning / notification in the Introduction page, which summarizes all the conventions used. Would have saved many beginners a lot of time. I am an experienced programmer and was very frustrated having to search for all the conventions used in the framework.

That always drove me nuts. You need to learn all those conventions from the examples. And then you always got the strangest surprises and still needed to use attribute based routing.

Something that drives me crazy about the current ASP.NET Core documentation is that it is overly example based. I wish there were more comprehensive coverage of the subsystems.

Re: Minimal APIs at a glance in .NET 6

#77

Post by andix »

Rapzid wrote: post #76
andix wrote: post #42

Earlier quoted context omitted.

That always drove me nuts. You need to learn all those conventions from the examples. And then you always got the strangest surprises and still needed to use attribute based routing.

Something that drives me crazy about the current ASP.NET Core documentation is that it is overly example based. I wish there were more comprehensive coverage of the subsystems.

Totally. Most of the time I don’t even check the docs, I go straight away to the source code on GitHub.

Re: Minimal APIs at a glance in .NET 6

#78

Post by ripley12 »

jeswin wrote: post #15
ddek wrote: post #2

So I guess we've had 'JavaScript but like C#', in the form of TypeScript; so I suppose now we get 'C# like JavaScript'? I must admit, I find this amusing. I suppose this raises two questions: "Why use C# like this in place of express or koa on node, which idiomatically similar?", and "Why use C# like this instead of C# like that (the way all other AspNetCore apps do it)?"

1. The web server component could be fronting a middle-tier written in C#. There are numerous advantages to doing this in .Net over Node. 2. Performance. 3. Native AOT is coming in 6.0. Meaning, you get a native platform specific app which can run without the framework - like golang. But with GC, so not like C/C++/Rust.

NativeAOT is supported in more places in .NET 6, there has been a tremendous amount of work to ensure that libraries are trimmer and linker friendly. But I believe ASP.NET’s targeting .NET 7 for that.

Re: Minimal APIs at a glance in .NET 6

#79

Post by coldacid »

giobox wrote: post #71
corpdronejuly wrote: post #48

Earlier quoted context omitted.

The bigger issue for me will be the way that these kinds of things tend to split communities. It doesn't do big enterprise devs much good if we have a lot of cool new features if there's no path towards using them in our 20 year old legacy applications that keep the business running.

If you are a server side web app, the migration process from legacy net Framework app to net 5/6 has gotten _a lot_ easier in past few years. The biggest barrier for most in my experience has been getting through the project file (*.csproj) changes needed. Even today, there is still no fully automated way to do it. Thankfully, after ~4 years of community complaints, Microsoft finally aquiessed and made a CLI tool tha…

I don't think moving from legacy .NET Framework to modern .NET is the issue here. I have a web API application that has moved from .NET Framework 4.5 to .NET Core to .NET 5 and just updating for the newer framework has been the simplest part of each upgrade. The real problems come with the changes to the ASP.NET libraries and the changed expectations regarding how such applications are built.

This push towards the "minimal APIs" for .NET 6 may be great for trivial or just-bigger-than-trivial projects but it starts falling apart whenever you have something more complex. The setup class system of older ASP.NET editions, while decried as boilerplate, actually makes it easier to manage the configuration and structure of larger web app projects.

I don't expect to ever move any of the ASP.NET projects that I work on to use these minimal APIs, and I expect that any new projects will be quickly adapted away from them out of the new project templates out of Microsoft.

Re: Minimal APIs at a glance in .NET 6

#80

Post by tonyedgecombe »

zzbzq wrote: post #53
0xcoffee wrote: post #13

Is there any example of how this would work with dependency injection? Or it's expected to manually call the service provider inside the lambda? Or if I just add my interfaces to the lambda parameters they will automatically resolved? edit: It supports DI using `[FromServices]` attribute! https://gist.github.com/davidfowl/ff1addd02d239d2d26f4648a06... edit: Apparently this was in the article, but I overlooked it..

The target audience for it, though, is probably us folks who want to remove dependency injection altogether. It was going against the grain before because the whole framework was built around Controllers and the part of the pipeline that had a monopoly on constructing them. With these changes it looks like it will be fully supported to write server-side HTTP code as if it were a computer program. Like you can in any…

That's interesting, I've been avoiding .Net for web projects because of the DI. Time to take another look.
Post reply on HN