Visste du at du kan sette opp et .NET API med bare fire linjer kode?

Jeg anser meg selv som en fullstackutvikler. Likevel har jeg de siste par årene jobbet aller mest med frontend, så jeg har mildt sagt ikke .NET i fingrene for tiden. For å være ærlig føler jeg aldri at jeg egentlig har hatt det. Men i høst kom en i teamet som jobber med markedsføring bort til meg og sa noe sånt som: «Jeg trenger regelmessig oppdatert data fra et åpent api, bare på et litt annet format, som datakilde til et annonseringsprogram jeg bruker. Jeg kan spesifisere datakilden som en url».

På grunn av diverse begrensninger kunne vi ikke lage dette som en enkel funksjon i skyen, som kanskje ville vært førstevalget (Lambda+API Gateway i AWS). Og organisasjonen bruker .NET. Så her luktet det å sette opp et enkelt .NET API. Men…«et enkelt .NET API? There’s no such thing», tenkte jeg. Masse boilerplate. Selv om vi bare trenger et enkelt endepunkt. Og som attpåtil kan ligge helt åpent, uten autentisering. Likevel, et .NET API med controllere virket i overkant overkill.

Men jeg lagde nå en lapp og la den nederst i backloggen med taggene “størrelse: medium” og “viktighet: medium-lav” og tenkte at den kan vi plukke opp Etterhvert™. Ikke et spesielt godt utgangspunkt for en ung og lovende tjeneste som drømmer om å reise til det forgjettede landet “Produksjon”.

«Har du hørt om “Minimal API"?»

Så en dag gikk jeg for å ta den rutinemessige etter-lunsj-kaffekoppen for å motvirke 14-knekken og kom i prat med en av infrastrukturlegendene i organisasjonen. Han kunne fortelle at det finnes en enklere måte å lage endepunkter på i .NET 7. Mindre boilerplate. Færre filer. Raskt å sette opp. Perfekt for mitt use case!

La det bli lys!

Det han snakket om var "Minimal API". Den aller enkleste veien for å teste ut dette er å huke av "Use controllers" når du oppretter et nytt .NET Core API i Visual Studio 2022, og ikke minst velge .NET 7.

Da får du et enkelt oppsett hvor med et GET-endepunkt, hvor alt skjer i Program.cs fila! 4 kodelinjer er alt som skal til - vel å merke for å sette opp det aller enkleste endepunktet man kan tenke seg, men likevel. Og med .NET 7 blir det meste abstrahert bort på magisk vis:

Er dette vanlig .NET Core?

Jepp! Med andre ord er det for eksempel relativt enkelt å skrive om til å bruke vanlig controllere hvis det viser seg at man trenger mer struktur, eller det er noen features man trenger som ikke er tilgjengelig med Minimal APIs.

Hva med dependency injection?

Mulig det også! Selv uten en konstruktør. Her er det mer .NET 7-magi som abstraherer bort det meste:

CRUD sa du?

Du gjettet riktig: i likhet med app.MapGet() finnes det støtte for resten av CRUD-metodene også. Under er et enkelt eksempel på hvordan man kan hente ut data fra body'en til en POST request mot /ønskeliste ruten:

Selve requesten og resultatet fra kallet ser da slik ut:

Hva med autentisering?

Autentisering i .NET Core gjelder også for Minimal APIs. Har man satt det opp er det bare å slenge på en [Authorize] attributt på endepunktet, på samme måte som man ville gjort på et endepunkt i en controller.

Blir det ikke fort rotete?

Joda, det kan fort bli uoversiktlig med alt i Program-fila. Men det er lett å organisere koden bedre! For eksempel ved å flytte ut selve logikken i endepunktene til egne service'er, som jeg så vidt var inne på ifm. dependency injection. 

Når bør man heller gå for vanlige controllere?

Godt spørsmål! Jeg aner ikke. For mitt use case var tjenesten så liten at dette føltes helt riktig. Da med alt stappet inn i Program.cs. Og for eksempel i en mikrotjenestearkitektur kan det godt hende at dette er et godt valg for noen av tjenestene hvis funksjonaliteten er begrenset nok.

Hva med (…)? Og (…)?

Les mer her! https://learn.microsoft.com/en-us/aspnet/core/fundamentals/minimal-apis?view=aspnetcore-7.0 



Ønsker du å lære mer om forskjellene mellom Minimal APIs og API med controllere kan du lese mer om det her: https://learn.microsoft.com/en-us/aspnet/core/tutorials/min-web-api?view=aspnetcore-7.0&tabs=visual-studio#diff-v7

Minimalistisk API i .NET på 1-2-3-4

The real world is a difficult place. So difficult that you sometimes have to work on an old Monolithic application built with legacy technology. But is there a way that allows you to at least share code between the old and the new?

YouYou work as a developer for We’ve All Been There Inc. (WABT Inc.), and you have recently made a new API. This API will serve as a crucial component in WABT’s systems portfolio. Several systems need to integrate with it. Amongst them is “The Monolith” – an application running on .NET Framework (4.8). Your new API is a long step in the direction of splitting The Monolith, but there is still a long way to go. So you've still got to deal with legacy .NET for the foreseeable future.

To enable simple integrations with your new API, you decide to write a C# client library. The library should be distributed as a NuGet package and it has the following requirements:

The client should utilize structured logging for debug and informational purposes.

The team already has a library for logging in NET48, as this is not a native part of the framework: Wabt.Logging

There should be an easy way of integrating the client with Dependency Injection (DI) systems in both NET5.0 (new systems) and NET48.

The Monolith uses Ninject for DI.

Using HttpClient to call an API is straight forward. If it wasn’t for the other requirements, the library would target netstandard2.0 and both it and this blog post would be over:

With the extra requirements, it seems that targeting both net48 and net5.0 is unavoidable. But you don’t like the idea of having #if directives all over the place. Is there any way you can have clean code, that is easy to maintain? Both the shared parts and the framework specifics? Having #if directives everywhere sure isn’t clean, nor easy to maintain. So you need to think smart when solving this.

You decide to get the project file out of the way first. The csproj-file at least has simple constructs to allow you to define multiple TargetFrameworks. You can also define specific dependencies for each target using a Condition.

With that out of the way, you decide to tackle the ApiClient. Inspired by an example from the .NET Docs, your first attempt looks like this:

"Clean code, that is easy to maintain" isn’t what comes to mind when you look at this. There are still features to be added to the ApiClient and there’s #if directives everywhere. There has to be a better way. If you could maybe isolate the parts that are different depending on the target. In this case, that is the logging. So you do what any other great developer would do – you create a wrapper:

Okay, so this approach has an obvious downside. You now have to duplicate every logging method you need instead of leveraging the respective interfaces. But since you only need a few of them, it may be a trade off worth making. Because now, the ApiClient looks like this:

No #if directives! In fact, it is completely oblivious to the multitargeting happening within ClientLogger. All you need to do now is make sure that ClientLogger is wired up in DI whenever someone tries to use the client.

When it comes to DI, the task of supporting Ninject for net48 and the standard IServiceCollection for net5.0 isn’t all that complicated. While the two approaches share the main functionality, they are fundamentally different. So the simplest way is to have two different static classes with extension methods for IKernel and IServiceCollection respectively:

Notice the #if directives. The entire file is dependent on the framework. So the net48 version does not contain ServiceCollectionExtensions.cs and the net5.0 version does not have NinjectExtensions.cs. So now The Monolith can use kernel.AddPingApiClient() and the other applications can use services.AddPingApiClient() - both from the same package.

This approach works well in this particular case. But if there was another project in WABT’s portfolio that has an Autofac based DI-system while also targeting net48, it would be a little messier. This project does not need to reference Ninject. If you find yourself in this position, you are better off splitting the DI-extensions into separate libraries instead. Maybe keep the IServiceColleciton-part in the core library (still for net5.0 only) and make separate ones for Ninject, Autofac and others you need.

When you look back at your multitargeting client library, you realize that your method builds on known principles. Isolate the ugly parts and build neat facades hiding it from the rest. That makes your code easier to maintain. It also makes writing tests simpler. And the best part about that is that you can target multiple frameworks in a test project as well. Running dotnet test will run your tests once for each target. Now you’re thinking with multiple targets!

Multitargeting class libraries in .NET

ASP.NET Core is not supported on Heroku. Read how I didn't care about that and made it work anyways (and all the hoops involved).

Recently, I started a hobby project that I for once was determined to finish. And that within a strict timeline too: NamR, an app to register baby names and compare them with your significant other’s. (Disclaimer: it's a Norwegian app designed by a developer for personal use. You have been warned).

As a .NET developer, and a notorious non finisher of hobby projects, I wanted a simple, clean and, most importantly, free way of running my app. Almost everyone I know that don’t see themselves as a .NET developer recommends Heroku for these very reasons, so I though I'd give it a try.

However, .NET is not supported on Heroku 😢. Though there is a way to do it anyway: Containers 🐋

With various assurances that a containerized .NET app will indeed run on Heroku, I decided to try it out. But as you might have guessed, completing this task wasn't as straightforward as those assurances assured. And that's why I'm writing this blog post.

The quirks of running .NET in a container on Heroku

NamR’s architecture is as simple as:

A .NET 5 Web Application with a Blazor Web Assembly front-end running on a free Dyno.

A Postgres database using the Heroku Postgres add-on.

Since this blog post is all about how I got the app running, I will not go into more details about the app itself, nor how to set things up in Heroku (they have plenty of documentation for that purpose).

The rest of this post will refer to (and show) examples from NamR's code. Feel free to have a look.

Before deploying I wanted to have a functioning application that talked to the database running locally. After that, I went ahead and created my Dockerfile and pushed the image to Heroku so that I could start working through the hoops necessary to make it run.

The port problem

The first quirk is how Heroku dynos handle ports when running containers. Normally when you run a container you specify port mappings and such in the Dockerfile. In Heroku, your container needs to support being assigned a random port through the $PORT variable. For a .NET app, that means you need this in your Dockerfile:

But wait, there’s more! You also have to configure Kestrel, .NET’s default web server, to listen on this port:

With that out of the way, you should be able to reach your app on Heroku so that you can behold the error message it displays in all its glory. But hey! At least this proves that you have configured the port correctly. Because the error message is coming from the application itself, and its telling you that it cannot access the database.

Next problem: connecting to the Heroku Postgres database.

Heroku provides connection details for the database as an URL via an environment variable: DATABASE_URL. But EF Core will not eat connection details in any other format than a connection string like this one (more properties exist):

To fix that, you need to tweak your Startup to handle translating the DATABASE_URL to a connection string:

Migrate the database

Another issue is how to handle migrations. Personally, I prefer to run migrations locally using a command line tool like dotnet ef, and in various environments this should be done during deployment. However, in this case I decided to just run migrations during application startup:

What about HTTPS?

You may now visit your app. Open a browser and type in "yourappname.herokuapp.com" and witness the beautiful 404 you're greeted with. That’s right. There’s one more thing: HTTPS redirect.

This is usually something you get out of the box with the code provided in a .NET Web App template, but in a container on Heroku you need to handle this a little different (this may also apply behind other forms of reverse proxies):

Why you ask? You shall find the answer in Heroku’s documentation:

Under the hood, Heroku router (over)writes the X-Forwarded-Proto and the X-Forwarded-Port request headers. The app must check X-Forwarded-Proto and respond with a redirect response when it is not https but http.

That is what the code above does. And then finally, we redirect to https using a 307 status for internal redirects 🔐.

And that’s it! You should now be able to focus on developing (or procrastinating) your awesome hobby project. Best of luck!

.NET

Minimalistisk API i .NET på 1-2-3-4

Multitargeting class libraries in .NET

Running an ASP.NET Web Application on Heroku

Sign up for our newsletter

Join in the holiday cheer and count down to Christmas with us!