Minimal APIs at a glance in .NET 6 • Hacker News Board

Re: Minimal APIs at a glance in .NET 6

#81

Post by jayd16 » Mon, Sep 13, 2021, 3:48 PM UTC

Hawxy wrote: post #30

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…

I've recently started using the new .NET 6 templates and honestly I don't miss the OOP boilerplate. Yes it's a bit of a shock at first, but you quickly realize that having your ASP.NET Core startup code split into two files and three functions has no real-world benefit. I'll still be using traditional controllers for my endpoints, however the syntactic sugar in C# 10 does improve the experience by reducing nesting an…

>code split into two files and three functions

You could always put multiple classes in a file if you wanted to organize that way. The new language changes just reduce nesting and boilerplate the IDE already took care of. (which isn't nothing). These framework changes to focus on lambdas is pretty nice though.

Re: Minimal APIs at a glance in .NET 6

#82

Post by andix » Mon, Sep 13, 2021, 3:52 PM UTC

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.

There is normally not such a big benefit in unit testing them, as controllers should only call some service behind. This service you can test.

Controllers are better integration tested, with a mock service behind. So you actually test if your routing and response codes are picked up correctly by the framework.

There is TestServer for asp.net core. It gives you a very easy solution for integration testing, if set up correctly they are nearly as fast as plain unit tests.

Re: Minimal APIs at a glance in .NET 6

#83

Post by jayd16 » Mon, Sep 13, 2021, 3:53 PM UTC

arethuza wrote: post #50

andix wrote: post #20

Earlier quoted context omitted.

It is still some kind of reflection magic. Also most frameworks moved away from attributes and towards builders. For example entity framework or Microsoft.extensions.dependendyinjection.

What's so bad about using reflection and attributes in this context?

Probably attributes have to be added to classes, builders can receive types through a method. If you can't change the code, you can't use attributes.

Construction time is also probably the safest place to inject dependencies.

Re: Minimal APIs at a glance in .NET 6

#84

Post by andix » Mon, Sep 13, 2021, 3:57 PM UTC

Jenk wrote: post #64

tester34 wrote: post #40

Earlier quoted context omitted.

But why? generally you don't test controllers directly. You test "service"/"handler" classes that handle those requests. If you want to test controllers, then you write E2E tests that send HTTP requests Here's some example of how it might look like https://docs.microsoft.com/en-us/aspnet/core/test/integratio...

Controllers still control, believe it or not. I want tests to assert that I return a file type. Theres method on the base controller for doing that. It, too, is protected. So I need to wrap my controller in a test. Need to assert that the response differs based on the content of a header, or a cookie? Need to use test the controller. etc. The basest of assertions I want tested is that the controller returns/uses the…

But there are multiple ways to return a file type. There are also multiple ways to define a route. You can name the method item[] GetItem() or use attributes [HttpGet] item[] Items().

If you do integration testing, you verify what will be returned in the end to the caller over http. For that you don’t need selenium. Just use testserver, it’s just a few lines of c# Code.

Re: Minimal APIs at a glance in .NET 6

#85

Post by phillipcarter » Mon, Sep 13, 2021, 3:58 PM UTC

I love this, not because of the "it's for beginners" framing, but from a "I want less boilerplate" framing. I look forward to a future .NET that gets less verbose each release, regardless of language chosen.

Re: Minimal APIs at a glance in .NET 6

#86

Post by phillipcarter » Mon, Sep 13, 2021, 3:59 PM UTC

reverseblade2 wrote: post #22

I like giraffe better. https://github.com/giraffe-fsharp/Giraffe

I do too! One thing I do hope happens is Giraffe is able to use some of the newer APIs to simplify configuration. Config is generally something you stuff in a file to not look much at, but it can sometimes feel kinda hairy.

Re: Minimal APIs at a glance in .NET 6

#87

Post by oaiey » Mon, Sep 13, 2021, 4:22 PM UTC

andix wrote: post #77

Rapzid wrote: post #76

Earlier quoted context omitted.

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.

True story. We developers are an interesting species. Documentation is for us never sufficient because we want to know how the sausage is done down to the if statement.

And for good reasons.

Re: Minimal APIs at a glance in .NET 6

#88

Post by oaiey » Mon, Sep 13, 2021, 4:31 PM UTC

inshadows wrote: post #17

flohofwoe wrote: post #3

Translation for non-web-people: how to write a minimal web service in dotNET. I probably missed when the acronym "API" was hijacked by the web people to describe a custom web service protocol.

Also the word "public" is missing. Cute examples, but I guess you're supposed to set up firewall for auth.

You can just add auth middleware in there. This is still full fledged ASP.NET Core. They just wire it up using a different style. There is a chapter in the referenced gist about adding middleware.

But I guess you more meant the example than the actual tech.

Re: Minimal APIs at a glance in .NET 6

#89

Post by moogly » Mon, Sep 13, 2021, 4:48 PM UTC

DonnyV wrote: post #69

Things start getting a little verbose with everything on 1 line thrown inside a function. app.MapGet("/todos/{id:int}", [Authorize("AdminsOnly")] (int id) => "This endpoint is for admins only"); Attributes make things cleaner with everything having its own line. Also you lose the ability to group a bunch of methods in 1 controller together under the same authentication policy.

There is a multitude of ways in which you could format that code:

  app.MapGet(
      "/todos/{id:int}",
      [Authorize("AdminsOnly")](int id)
          => "This endpoint is for admins only");

Or for people who don't like expression bodied members:

  app.MapGet(
      "/todos/{id:int}",
      [Authorize("AdminsOnly")](int id)
      {
          return "This endpoint is for admins only");
      });

Extracted to a method:

  app.MapGet("/todos/{id:int}", GetTodos);

  [Authorize("AdminsOnly"]
  string GetTodos(int id) => "This endpoint is for admins only";

And more...

You could also put these methods in a class and put the attribute on the class, which would solve your "grouping" problem.

Re: Minimal APIs at a glance in .NET 6

#90

Post by moogly » Mon, Sep 13, 2021, 4:52 PM UTC

andix wrote: post #84

Jenk wrote: post #64

Earlier quoted context omitted.

Controllers still control, believe it or not. I want tests to assert that I return a file type. Theres method on the base controller for doing that. It, too, is protected. So I need to wrap my controller in a test. Need to assert that the response differs based on the content of a header, or a cookie? Need to use test the controller. etc. The basest of assertions I want tested is that the controller returns/uses the…

But there are multiple ways to return a file type. There are also multiple ways to define a route. You can name the method item[] GetItem() or use attributes [HttpGet] item[] Items(). If you do integration testing, you verify what will be returned in the end to the caller over http. For that you don’t need selenium. Just use testserver, it’s just a few lines of c# Code.

TestServer is great. And if you use Alba[1], it gets even better.

[1]: https://jasperfx.github.io/alba/guide/hosting.html