A minimal fully asynchronous C# ASP.NET Core 3.0 application with routing (learn more about ASP.NET Core here https://docs.microsoft.com/en-us/aspnet/core/?view=aspnetcore-3.0)

Program.cs

using Microsoft.AspNetCore.Hosting;
using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Http;
using Microsoft.Extensions.Hosting;

public class Program
{
    public static void Main(string[] args) =>
        Host.CreateDefaultBuilder(args)
        .ConfigureWebHostDefaults(webBuilder =>
        {
            webBuilder.Configure(app =>
            {
                app.UseRouting();
                app.UseEndpoints(route =>
                {
                    route.MapGet("/", context => context.Response.WriteAsync("Hello world"));
                });
            });
        })
        .Build().Run();
}

WebApp.csproj

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>netcoreapp3.0</TargetFramework>
  </PropertyGroup>
</Project>

Ill ask the most basic q: how do you run this microservice?

@bigopon dotnet run.

Here's the same thing in F# https://gist.github.com/slang25/90ed87767b62f5c4f43a7b691e98f2ee

I think this is the wrong metric. With all this stuff done for you, the question becomes how productive am I when I don't want the defaults? Productivity isn't count of lines of code. How long does it take me to learn the terse syntax?

Writing many lines of code but intuitively and without reading blogs, asking SO and trawling documentation and then adjusting for changes since vPrevious can be much more productive.

I think this needs to be kept in mind when designing ASP.NET Core (and any other API/SDK).

Productivity absolutely includes lines of code but it’s isn’t the only measure. Those lines of code also have to make sense and those concepts need to scale up as the application grows in complexity (which I think we’ve accomplished)

I'm not so sure. I think great APIs are about discoverability and designs that are subtly instructive. The time lost to "it not working" can be days. How many lines of code per day are lost to head-scratching? Maybe its an Availability Bias but I've recently found it harder to figure stuff out for myself in ASP.NET Core.

Some examples here:

dotnet/AspNetCore.Docs#13019 (comment)

Note the response was that "I have taken more control" by using AddIdentityCore instead of AddIdentity, he sees it that way because he has the Curse of Knowledge.

https://stackoverflow.com/questions/56835443/how-to-disable-csrf-antiforgery-in-razor-pages

This one just works differently for some reason, breaks The Power of Sameness. I find I have to read the source code a lot. I began to wonder if that's intentional since going open-source.

My point is to challenge accepted wisdom that fewer lines of code and smart quick setup immediately means a more productive experience when everything is a trade-off and sometimes the trade is invisible or hard to measure.

Note the response was that "I have taken more control" by using AddIdentityCore instead of AddIdentity, he sees it that way because he has the Curse of Knowledge.

I'm not sure how you could even communicate that in an obvious way without forcing you to write more code so it feels more "like you took control" or if a doc comment would have helped. I could ask you a similar question, what lead you to call AddIdentityCore vs AddIdentity? Intellisense/Docs/Guessing?

This current API naming is our "scheme" of exposing the guts so other functionality can be built and having an uber method that sets up all the defaults. It's very much like exposing the atoms and make up the molecule and exposing the molecule itself.

My point is to challenge accepted wisdom that fewer lines of code and smart quick setup immediately means a more productive experience when everything is a trade-off and sometimes the trade is invisible or hard to measure.

There are no absolutes in this business, it's more of an art than it is exact science. See .NET Core 1.0 where everything was explicitly painfully spelled out and verbose. You may not think number of lines of code matters but it actually does matter and of course as I said in my previous comment, it's absolutely not the only measure of a great API or good productivity. The answer lies somewhere inbetween being to explicit and having too much hidden behind simple looking APIs.

It's only now occurred to me that the Core means the "core" of identity. I thought there were now new ways to set things up in the latest ASP.NET Core, so these Core extensions were added leaving the old ones not breaking existing code. Crazy as it sounds, I thought Core was just on-brand. I mean, Core is the framework name afterall.

I'd counter that forcing people to write more code isn't a design failure, just as twisting more knobs, pressing more buttons, gesturing more or clicking more hyperlinks isn't a failure of interaction design.

Anyway, maybe a design where those extensions were reached via an intermediate extension would be better. I'd also favour something like services.ConfigureEssentials().AddIdentityEssentials() perhaps.

On the second point, we agree.

Ah, I also now see that AddIdentity forces me to supply TRole which I don't want to supply, since I have no concept of roles in my app.

My final addition to this thread is to ask that work is done on an API design that makes it easy to "fall into the pit of success" regarding correct order of these extension methods.

See this.

https://stackoverflow.com/questions/56842367/controller-user-has-no-claims-even-though-identity-applicaton-cookie-is-sent

Sure, I don’t see how adding more undiscoverable methods helps that but your point is taken

Glad to see these improvements. Do you think we can bring it down to 3 lines? 😉

var app = Host.CreateDefault(args);
app.Get(“/“, context => context.Response.WriteAsync(“easy”));
app.Run();

@BuddySpike, not with the same types but a different API optimized for web scenarios could be that simple. What we have today is a generic host not tied to web that we use for background workers as well (so single shared type for different types of apps). Plus the web specific host wire up nested inside of it.

That’s the sort of competition ASP.Net Core has today. For example, http.HandleFunc in Go or express in node has a very similar API.

@BuddySpike Such a ridiculous comment. No disrespect, but I find it hard to not see the elegance in the code presented here. Sure, can C#/.NET claim it has as small a surface area as Go? Absolutely not. The language has been maturing for almost 20 years, .NET roughly the same. But, if you're programs are backed by .NET Core chances are you're writing fast, succinct and simple-to-reason-about software. If you want to stick around at the handler level, we call them RequestDelegate's, you absolutely can. The built in router, or mux if you want to be silly and fancy, is fantastically designed and has auto parameter mapping built-in (no slicing through the URL.path required).

@davidfowl Love this! Such an emphasis on bare bones these days, and I feel as though .NET is sometimes still viewed as cumbersome. Which I don't believe is the case at all.

Created a version without the default host builder, to make things a bit more explicit for potential newcomers. Seeing this as a potential acorn for new projects!