.NET Minimal API’s: performance, efficiëntie en eenvoud

Als .NET-Developer heb je mogelijk al gehoord van (en wellicht ook al gewerkt met) Minimal API’s. Deze feature is geïntroduceerd met .NET 6 in 2021.

De API’s zijn ontworpen om eenvoudiger, sneller en minder boilerplate-code nodig te hebben dan de traditionele Web API’s. Pas wel op, als je geen structuur aanbrengt, kunnen ze snel onoverzichtelijk worden.

In deze blogreeks duiken we dieper in de geschiedenis van Minimal API’s en hoe je deze slim gebruikt, met een focus op performance-optimalisatie en structuur.

We kijken hoe we deze out-of-the-box kunnen gebruiken, structuren en hoe we dit nog verder verbeteren met gebruik van het Request-Endpoint-Response pattern en met bekende NuGet packages.

Waar komen Minimal API’s vandaan?

Het concept van Minimal API’s is verre van nieuw. Je kan zelfs zeggen dat Microsoft met .NET te laat op het feestje is verschenen. Verschillende programmeertalen en frameworks hebben namelijk hun eigen interpretaties van “less is more” al jaren geleden geïntroduceerd.

Één van de meest bekende varianten op een ander framework is de Express.js package op Node.js.

Het doel van Minimal API’s is om het ontwikkelen van API’s te vereenvoudigen met name in een microservice of container architectuur. Ze richten zich op lichte, efficiënte en eenvoudige structuren voor API’s.

Minimal API’s met .NET

.NET voegde zijn eigen versie van Minimal API’s toe in .NET 6 (2021), geïnspireerd door frameworks zoals Flask en Express. Het doel? De eenvoud van andere talen naar de wereld van .NET brengen.

Niet alleen brengt Microsoft met Minimal API’s eenvoud naar .NET, ook brengt het daarin een stuk meer performance, met focus op de microservice architectuur.

Minimal API’s zijn met name sneller (dan praten we over milliseconden) maar alloceren ook een stuk minder resources. Bij een vergelijking met een simpele API in de traditionelere WebAPI praten we over een verschil van bijna 55% (1.18mb vs 2.13mb) in de geheugen allocatie. Met de komst van .NET 9 heeft Microsoft hier nog meer snelheid en efficiëntie behaald.

Hoe zet je Minimal API’s op in .NET?

Voor het opzetten van Minimal API’s heb je ontzettend weinig boilerplate code nodig.

Het aanmaken van een Builder en deze bouwen, zoals bovenstaand voorbeeld, is voldoende om de basis te registreren. Vanuit de app, in dit geval een Web Applicatie, is het direct mogelijk om REST-methode’s te mappen met een gewenst pad en bijbehorende parameters. Ook is het mogelijk om de HttpContext en geregistreerde services vanuit de dependency container te benaderen.

Microsoft maakt het de ontwikkelaar makkelijk door alle functionaliteit, welke deze gewend is bij WebAPI, ook te gebruiken met Minimal API’s. Zoals bovenstaand genoemde toegang tot dependency injection, maar ook het mogelijk maken van async handlers in het mappen van de REST-methodes.

Wat is het verschil tussen Minimal API’s en Web API’s?

Om een goed beeld te krijgen van de kracht en de minimale opzet, trek ik een vergelijking voor basale zaken in Minimal API en Web API. Beide stukken code hebben de IRepository geregistreerd in de Dependency Injection container en worden in de constructor geresolved.

Wat meteen opvalt is dat voor Minimal API’s een stuk minder boilerplate code nodig is om een werkende API op te zetten. Het opzetten van Controllers met modellen is niet nodig. Alles kan in de program.cs gedefinieerd worden. Dit maakt het erg makkelijk om een werkende proof of concept te bouwen en vanuit hier door te ontwikkelen naar een productiewaardige applicatie.

 

Valkuilen met Minimal API’s

Eén van de grootste valkuilen met Minimal API’s is de structuur, of beter gezegd, het aanhouden van structuur. Omdat het zo ontzettend simpel is om snel endpoints aan te maken in hetzelfde bestand, is het makkelijk om het overzicht te verliezen en ervoor te zorgen dat uiteindelijk alles her en der komt te staan. Dit zorgt ervoor dat code moeilijk te onderhouden wordt en eigenlijk op deze manier niet geschikt is voor een productieomgeving. Uiteraard zijn er meerdere manieren om dit probleem te vermijden, maar daar gaan we op in de volgende blog van deze reeks.

Conclusie

De keuze tussen Minimal API’s en de meer traditionelere Web API projecten hangen af van de vereisten van je project. Minimal API’s zijn ideaal voor lichte, eenvoudige projecten en bieden een iets betere prestaties, terwijl traditionele Web API’s beter geschikt zijn voor projecten die geavanceerde functies en meer controle over de implementatie van de API vereisen.

Het prestatieverschil is miniem en vooral te vinden in het geheugengebruik van jouw applicatie, maar is weldegelijk aanwezig.

Met Minimal API’s kan je snel Proof of Concepts ontwikkelen en snel vanuit daar verder bouwen. Daar zit meteen de valkuil van structuur in. Hoe bewaken wij deze of moeten wij toch kiezen voor WebAPI?

Maar wat als je de krachten van beide manieren zou kunnen combineren? De snelheid van Minimal API’s met de structuur van Web API-projecten? In het volgende deel van deze blogreeks gaan we in op de REPR (Request-Endpoint-Response) design pattern en kijken we hoe we structuur kunnen aanbrengen.