Minimal APIs at a glance in .NET 6

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.

> I think the only OOP is the instantiation of the controllers ... which are instantiated per request => pointless ;).

which has nothing to do with oop. that is IoC and they are (by default) scoped per request (but do not need to be scoped per request, singleton controllers are fine. (AddControllersAsServices)) btw. controllers by default do not get "built" by IoC but the helper "ActivatorUtilities#CreateInstance<T>(IServiceProvider, Object[])" uses it to resolve dependencies of the controller. if you add "AddControllersAsServices" it will use the IoC directly and skip using "ActivatorUtilities#CreateInstance" (and the IServiceProvider of the controller as created with the IServiceScopeFactory) and you can basically overwrite the behavior however you want, by using `IControllerFactory`.

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

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.

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 bother writing the testcase that asserts that if the controller is called with a valid body, it calls the right service and passes on the request data. Write the testcase that asserts that if it's called with a body that's way too big that it throws the appropriate 400 exception, though.

One of the biggest problems with web frameworks which let you configure a lot of stuff like caching, auth and parameter validation using attributes, DI, or magic syntax, is that often the only way you can verify those behaviors are in place is with integration tests. And integration tests for failure modes are hard to write, so they don't get written. Which means it's easy to deploy a service which, say, is supposed to respond with stale cached data if a dependency is unavailable - but it actually doesn't because nobody was able to express a test case that verified that the controller caching attributes actually work the way they thought it did.

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"

And is very much appreciated.

You test the integration of your code with the web framework. An integration test doesn't have to be end-to-end. It tests the integration between multiple components. In this case it would be your code with the integration of asp.net core.

A controller usually doesn't contain any business logic, it does the HTTP part. So you test serialization, model binding, return codes, etc.

So you use a mock to check, if the framework does the expected model binding. If the values you post via JSON end up in the right properties for the service call.

a typical controller method would look like that:

   IActionResult StoreProduct(Product p) {
      var success = service.Store(p);
      return success
         ? Ok("Stored")
         : BadRequest("Product doesn't contain all necessary fields");
   }

There is no reason to unit test this controller, because the code is trivial. But it makes sense to integration test it, and verify the serialization and binding of Product works, if the correct status codes and content types are returned. Because that could go wrong.

It is often easier to do that with a mocked service, but you can also use the real service for that. Often this would hit the database and make those tests much slower and harder to set up.

Suave can do an API server in a few lines in an F# script file - I think it’s even terser than ExpressJS, which requires a package.json.

Funny, that David ends this discussion.

Thanks!

PS: oh no, now I am ending it :)

This is more functional. C# is an multi paradigm language.

There is not a big difference between an FP module and an OOP static or single instance class.

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

yeah and the sad thing without NativeAot there won't be the WebAssembly things which we would like. the way it works now is way too lazy for anything real world. (compiling the runtime to wasm and loading dll files...)

There is definitely a terminology problem. "Automatic memory management" is a more precise term than "garbage collection". It refers to the more user visible trait, and pairs better with the antonym of "manual memory management" which is much more commonly seen. I would encourage people to use "AMM" as a term even if in their coding they do not use it. :-) "AMM" also begs the right questions such as "automatic -- in what sense, exactly?" It also tracks with the primordial C "auto" for stack variables (the automatically managed part of C - yes I am aware modern C++ repurposed it). It might even make some discussions have less talking past each other. This kind of oceanliner ship is hard to turn, though.

There are a few high profile prog.langs and environments like Java/Go/old Lisp stop-the-world/etc. style where (some) people struggle with "GC". These struggles often give AMM itself a bad reputation - while C stack variables (often coupled with what people call "value types" today) are often the way to be very, very fast (yes, because of mostly CPU-private stacks..even so).

Nim is very fast and has many choices in AMM from none to Boehm-Wiser to its own tracing variant to a new extremely low overhead ARC and ORC that have more Rust-ike aspects (but copying in some cases to be safe which is just about 10x easier to use in deviousmeters). With a TinyC/tcc backend Nim yields near Interpreter/REPL-like edit/compile/test cycles. It's really a joy to write code in most of the time. People should look into Nim more.