Live data from Hacker News

Minimal APIs at a glance in .NET 6

hanselman.com

61–70 of 114 posts

Re: Minimal APIs at a glance in .NET 6

#61
post #60

Earlier quoted context omitted.

"if you load the routes from a database" Serious question (honestly not being snarky) - why would you want to do that?

I don’t know, nobody needs more the 640k of RAM, right? Maybe you have multiple modules, and depending on the configuration the routing changes. Or feature flags, that enable a breaking api change. Or a stupid customer that pays you a million dollar for custom routes. But what benefit do the attributes bring? You need to learn them by heart, on builders Intellisense can help you.

Well yes - if you need some kind of dynamically configurable routing then attributes aren't a good fit. I like the fact they are there right next to the relevant method...

Re: Minimal APIs at a glance in .NET 6

#62
post #60

Earlier quoted context omitted.

I don’t know, nobody needs more the 640k of RAM, right? Maybe you have multiple modules, and depending on the configuration the routing changes. Or feature flags, that enable a breaking api change. Or a stupid customer that pays you a million dollar for custom routes. But what benefit do the attributes bring? You need to learn them by heart, on builders Intellisense can help you.

Well yes - if you need some kind of dynamically configurable routing then attributes aren't a good fit. I like the fact they are there right next to the relevant method...

Another thing is, that attributes totally opinionate your code. You pull in a framework into your code.

If you - for example - write one controller you want to use with multiple frameworks (ASP.NET Core or Nancy), you need one controller per framework, just for the attributes.

I always found them more annoying then helpful. Most people seem to see it that way. Most frameworks are moving away from attributes for a good reason.

Re: Minimal APIs at a glance in .NET 6

#63

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...

If there's any critical behavior you're reliant on the controller (and, in frameworks like this, its attribute-driven configuration) to provide for you - throwing exceptions for bad requests, authentication or authorization, returning particular cache headers for particular response cases... I'd recommend looking for some way to write tests that, in isolation, go some way to let you assert those behaviors. Don't both…

For Selenium tests I've been setting up an actual instance of application in test with different Startup (e.g sqlite instead of real database) and running at different port

This way you can test those fancy things, but I agree it's kinda "hard" to get it working for the first time

Re: Minimal APIs at a glance in .NET 6

#64
post #33

Earlier quoted context omitted.

> At least when the controllers are all classes I can unit test them. I was always having great difficulty testing ASP.NET MVC controllers given the use of completely closed off, cyclical dependency, sealed class, properties like HttpContext. Helper libraries made it somewhat easier to set them up but they were always heavy tests as a direct result of the large object graph needed.

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 right view. That _should_ be trivial but no. Instead I must rely on a super heavy integration test, or worse, a selenium or other test that requires a user-agent and actual webserver, when all I want to is to assert that "View X" is returned for "Scenario Y"

Re: Minimal APIs at a glance in .NET 6

#65

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.

Considering these are http wrappers around program A (the web service) that allows program B (a client) to interact with program A, I'd say API is the correct term for what this is.

Re: Minimal APIs at a glance in .NET 6

#66

Earlier quoted context omitted.

If there's any critical behavior you're reliant on the controller (and, in frameworks like this, its attribute-driven configuration) to provide for you - throwing exceptions for bad requests, authentication or authorization, returning particular cache headers for particular response cases... I'd recommend looking for some way to write tests that, in isolation, go some way to let you assert those behaviors. Don't both…

For Selenium tests I've been setting up an actual instance of application in test with different Startup (e.g sqlite instead of real database) and running at different port This way you can test those fancy things, but I agree it's kinda "hard" to get it working for the first time

and wasteful. Starting up selenium et al is painfully slow compared to tests that run in <seconds.

Re: Minimal APIs at a glance in .NET 6

#68

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

Suave is a cleaner API in my view but Giraffe has better performance on the edges.

When I was doing F#, I loved both of these projects. I don't think we should always view ExpressJS/Sinatra (from Ruby) as "the standard", but there's also something to not having to do an hour of work before we can get endpoints serving responses.

Re: Minimal APIs at a glance in .NET 6

#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.

Re: Minimal APIs at a glance in .NET 6

#70
post #11

Earlier quoted context omitted.

You still get C#/.NET, with it's superior performance and type safety, but just without all the OOP bloat.

Wait, you think this is not OOP? var app = WebApplication.Create(args); app.MapGet("/", () => "Hello World"); app.Run(); You're creating an object and calling methods on it..

Also MapGet seems to be changing the state of the WebApplication object... which doesn't seem to be very functional?
Post reply on HN