The .NET Stacks #20: Route to Code, IdentityServer, community links

Dave Brock -

Based on my eating habits this week, I should probably rename this newsletter to The .NET Snacks.

This week:

  • Use “route to code” with ASP.NET Core
  • The IdentityServer project goes commercial
  • Understand Blazor Web Assembly performance best practices
  • Last week in the .NET world

Use “route to code” with ASP.NET Core

I’ve been thinking a lot about “route to code” in ASP.NET Core lately. There isn’t much out there but have found some good content: the ON.NET Show brought up the concept recently, and Anthony Giretti has been writing some nice posts about it lately, too.

As an ASP.NET developer, you’ve likely leveraged controllers in MVC or Web API apps. That is, the controller will intercept your HTTP request and handle routing for you—you can do some configuration, but it’s largely managed for you. This is great if you don’t need much control, but it sure adds a lot of ceremony (if you’ve ever wait for ASP.NET to scaffold a new MVC app, you know what I mean). You may have scenarios where you need fine-grained control, simplicity, or high performance without an explicit framework.

This “route to code” concept offers a solution somewhere between ASP.NET Core middleware and controllers—where you can handle routing right in the Startup.cs file of your ASP.NET Core project. You can get started by creating an “Empty” ASP.NET Core web app in Visual Studio.

If we look at Anthony’s example, he creates a list of countries and instantiates it in the Startup constructor. The fun stuff, though, is in the app.UseEndpoints middleware.

Here, we’re using the MapGet extension method—you use it to match the HTTP/URL method, and then execute by running a delegate (and yes, there are other methods for the other HTTP verbs). You can definitely use this in more complex ways—like using string interpolation to create routing templates, adding authentication, and dependency injection. It takes some getting used to after years of depending on controllers—but it’s a great way to cut straight to what matters.

The IdentityServer project goes commercial

This week, it was announced that IdentityServer—an open-source OpenID Connect (OIDC) and OAuth 2.0 framework for ASP.NET and ASP.NET Core—has gone commercial. With 12 million NuGet downloads to date for the IdentityServer4 package, this is a big deal. For most of us, we’ve used the free (for us) library for the last decade. While congratulations are in order for Brock Allen and Dominick Baier—and they should be praised for finding a path for sustaining the project over the long term—a logical next question is what this means for the greater .NET ecosystem.

From Dominick Baier’s post on the news:

The current version (IdentityServer4 v4.x) will be the last version we work on as free open source. We will keep supporting IdentityServer4 until the end of life of .NET Core 3.1 in November 2022.
To continue our work, we have formed a new company Duende Software, and IdentityServer4 will be rebranded as Duende IdentityServer. Duende IdentityServer will contain all new feature work and will target .NET Core 3.1 and .NET 5 (and all versions beyond).

What does this mean for use in your projects? IdentityServer4 is still free, and appears to always will be. However, in two years it won’t be supported and you won’t get any critical security updates for it. IdentityServer5 will have this new pricing model. (And short term, .NET will ship with IdentityServer 4 templates.)

As for that pricing model: this new Duende IdentityServer company will offer two versions of IdentityServer. You’ll have a free reciprocal public license (RPL) for folks using open-source work, and a commercial license that is paid (the exact charges based on company size and usage). I’m seeing the $1500 price point being passed around, but others have noted it isn’t so simple. You’ll also want to check out the lively GitHub issue that discusses where to go from here.

If you don’t want to pay for it, fine—you’ve got two years on IdentityServer4 and you can evaluate if less complex solutions like the out-of-the-box Microsoft.AspNetCore.Identity work better for you. If not, you can roll your own solution. To that I say: unless you’re a security expert you’ll probably find the cost in development time and headaches far exceeds licensing for IdentityServer (for most cases). If your company needs the complex use cases and can pay for it, my opinion is to do just that.

Understand Blazor Web Assembly performance best practices

This week, Steve Sanderson—the architect at Microsoft behind Blazor—announced he’s working on documenting Blazor Web Assembly performance best practices. While performance is always important, it appears doubly so when you’re loading a complete .NET runtime into the browser. I definitely learned a lot, and it’s worth a read.

🌎 Last week in the .NET world

🔥 The Top 3

📢 Announcements

📅 Community and events

😎 ASP.NET Core / Blazor

⛅ The cloud

📔 C#

📗 F#

🔧 Tools

📱 Xamarin

🎤 Podcasts

🎥 Videos