M.H. Jongerius

.NET Framework stopt? … o shit, maar wat betekent dat voor mij?

Als je kijkt naar de ondersteuning van de .NET Framework versies dan staan voor de meest recente versies nog geen eind datums genoemd:

Van .NET Framework 4.8 garandeert Microsoft support zolang het draait op een ondersteund Windows platform. Dat plaatst de einddatum rond 2029, maar gezien de uitdaging die bedrijven hebben om hun software om te zetten naar de nieuwe versie(s), verwacht ik dat deze datum nog naar achter kan schuiven. Het geeft wel aan dat er urgentie is om je bestaande systemen om te zetten, en een gedegen vernieuwingsstrategie op te zetten.

Wat is .NET 6

Met .NET 6 is er voortaan echt één platform dat voor alle doeleinden gebruikt kan worden. Een groot deel van de inspanning van Microsoft is gaan zitten in het optimaliseren van de prestaties en het stresstesten van .NET in productie scenario’s. Meer details vind je op: devblogs.microsoft.com/dotnet/performance-improvements-in-net-6/

Gemiddeld is .NET 6 een factor 10 tot 50 keer sneller dan .NET Framework 4.8 en een factor 2 tot 10 keer sneller dan .NET 5. Voor toepassing in IOT devices is dit een spectaculaire verbetering.

Functionele verbeteringen

Op het gebied van beveiliging zijn er een groot aantal uitbreidingen en verbeteringen doorgevoerd. Zo ondersteund .NET 6 voortaan  OpenSSL 3 en ChaCha20Poly1305.

Voor IOT en mobiele apparaten worden nu ook Arm64 processoren volledig ondersteund, op alle bekende besturingssystemen. Betere support betekent in dit geval ook dat .NET 6 beter draait in container oplossingen. Daarnaast is de ondersteuning voor Windows containers uitgebreid, hoewel dat misschien meer iets is voor de echte Microsoft fanaten, want ik ken weinig praktijkvoorbeelden van organisaties die voor hun lol iets met Windows containers doen.

Met de dotnet monitor is de monitoring voor containers behoorlijk uitgebreid.

Voor Windows Forms zijn op het gebied van de toegankelijkheid en het instellen van applicatie brede templates verbeteringen doorgevoerd. Ook is het voortaan mogelijk om de gecompileerde applicatie te comprimeren zodat deze minder schijfruimte in beslag neemt.

Gezien het intensieve gebruik van Websockets in verschillende bovenliggende technieken, is er geïnvesteerd in de performance en compressie van websockets.

Blazor for the win

Een mooie uitbreiding is er op het gebied van Blazor en dan vooral de mogelijkheid om met Blazor .NET MAUI apps te schrijven. Dit betekent dat je met één technologie platform single page web applicaties en native apps oplevert. Om sneller te laden is er een prerendering optie gemaakt waarbij de website de eerste pagina alvast op de server maakt en naar de client stuurt, terwijl de assembly componenten worden gedownload.

Verbeteringen voor de developer

Met de komst van .NET 6 komt ook de nieuwe versie van Visual Studio uit. Hierin zitten erg gave features waarvan de mooiste volgens mij de Hot Reload functie is. Deze functie maakt het mogelijk om een applicatie terwijl hij draait aan te passen. Daarnaast is Visual Studio voortaan 64 bit waardoor zelfs de grootste solutions niet meer voor geheugenproblemen zorgen. Ook op het gebied van samenwerking en personalisatie zijn veel verbeteringen doorgevoerd.

Tenslotte is natuurlijk ook C#10 uitgekomen, maar hier moest ik maar een losse blogpost aan wijden.

Conclusie

API driven development in een breder perspectief

Voordat ik de details in duik van de verschillende serviceprotocollen, wil ik stilstaan bij het waarom van deze ontwikkeling. Toen ik twintig jaar geleden begon met softwareontwikkeling, was het redelijk standaard dat applicaties als monoliet werden gebouwd. Dit model was eenvoudig en bestond vaak uit een client applicatie met een database. Naarmate applicaties groter en complexer werden, ontstond de wens om de monoliet op te splitsen in kleinere blokken. Een oplossingsrichting om hiermee om te gaan, was de Service Oriented Architecture. Binnen de Microsoft stack betekende dat meestal applicaties die opgebouwd waren uit WCF-services. Daarnaast kon je met deze services relatief eenvoudig externe partners aansluiten op je applicatie landschap. Nadeel is dat het gebruikte SOAP protocol log en relatief traag is. Met de opkomst van webapplicaties en apps werd in rap tempo overgestapt op WebAPI’s. De meeste van deze API’s voldoen aan de OpenAPI standaarden en implementeren in meer of mindere mate de principes van een RESTful api.

“ Risico van de populariteit van WebAPI’s is in lijn met de uitspraak: als je alleen een hamer hebt, ziet elk probleem er als een spijker uit.”

De laatste jaren zijn er naast de bekende OpenAPI standaarden nieuwe standaarden uitgekomen die elk hun eigen probleemgebied oplossen. Door de juiste techniek in te zetten op de juiste plek, maak je een betere softwareoplossing.

OpenAPI versus graphQL versus gRPC

Naast de populaire OpenAPI standaard, zijn momenteel graphQL en gRPC opkomende alternatieven. GraphQL is vooral krachtig wanneer je de client meer specifiek data wilt laten opvragen. Het is een mooie techniek waarmee aan de hand van een schemadefinitie de client specifiek gegevens op kan vragen bij een enkel query endpoint. GraphQL ondersteunt ook mutaties waardoor je snel een rijke client kunt bouwen. De gRPC standaard is ontwikkeld om snelle en directe communicatie tussen (micro)services op te zetten. Het binaire formaat maakt de communicatie effectief en de protobuffer contracten maken het een platformonafhankelijke oplossing.

Wat is gRPC

RPC of Remote Procedure Calls zijn een van de oudste manieren om API-communicatie op te zetten. De Google implementatie ervan is een nieuwe techniek om op uniforme manier machine to machine communicatie mogelijk te maken. De basis van een gRPC service is de servicedefinitie die in een protocol buffer file is opgesteld:

De definitie in deze proto file bepaalt hoe zowel de client als de server opgebouwd worden en vormt het contract tussen beide partijen. De gebruikte taal is goed gedocumenteerd door Google.

Op basis van de proto file zal Visual Studio alle benodigde code genereren om een server of client te maken. De implementatie van de code bepaal je zelf, door de gegenereerde base classes te implementeren:

Ook de client wordt automatisch gegenereerd op basis van de proto file:

Voorwaarden om gRPC te gebruiken

Een gRPC service draait alleen over http/2 met TLS. Wanneer je de native Kestrel server gebruikt binnen .NET, heb je standaard support voor http/2. Binnen IIS moet je extra werk doen om gRPC te kunnen hosten: zie hiervoor de Microsoft documentatie  

Belangrijkste voordelen van gRPC

Bijzonder lage latency

Optimaal om in een distributed systeem (micro)services met elkaar te laten communiceren

Breed ingezet door onder andere Netflix, Cloudfare, Google en Docker

Ondersteunt bi-directionele streaming

Wanneer gebruik je gRPC

Vrijwel alle implementaties van gRPC zijn bedoeld voor interne snelle communicatie in een distributed systeem. Een gRPC implementatie maakt het mogelijk dat twee services met elkaar communiceren met dezelfde eenvoud als wanneer ze een interne methode aan zouden roepen. Wanneer je gRPC services publiek toegankelijk wilt maken, zul je na moeten denken over de beveiliging. Een gRPC service ondersteunt token based security, maar je zult in dit geval zowel op de client als op de server extra code moeten schrijven. Een gRPC service is niet geschikt voor communicatie met web clients. Er zijn wel initiatieven op dit gebied met gRPC web, maar dat lijkt op zoeken van een oplossing voor een niet‑bestaand probleem omdat juist voor weboplossingen OpenAPI standaarden heel goed werken.

Kennismaken met gRPC

Er is goede documentatie beschikbaar over het implementeren van gRPC in .NET. De documentatie van Microsoft is een prima startpunt om je eerste eigen service op te zetten:

https://docs.microsoft.com/en-us/aspnet/core/tutorials/grpc/grpc-start?view=aspnetcore-5.0&tabs=visual-studio

Daarnaast is de documentatie voor het maken van de proto file goed beschreven:

Wat is rebase in vergelijking met een merge

Voordat ik verder in de details duik is het belangrijk om goed te begrijpen wat een rebase en een merge nu eigenlijk zijn. Hiervoor is het van belang om te begrijpen dat elke commit in git een setje aan veranderingen vertegenwoordigt ten opzichte van de commit ervoor:

In het voorbeeld hierboven is er een feature aangemaakt waarop een aantal commits zijn uitgevoerd. Bij het aanmaken van een feature branch, onthoudt git op basis van welke commit de feature gemaakt is en vervolgens wordt elke nieuwe commit daar aan vastgeknoopt.

Maar wat gebeurt er als in de tussentijd er ook wijzigingen zijn geweest op de master branch. Voordat de feature branch terug kan worden gebracht in de master branch (meestal met een pull request), wil je deze wijzigingen lokaal testen om te valideren dat er geen impact is op de wijzigingen die je zelf aan het maken bent.

Optie 1 voer een merge uit van de master naar je feature branch

Een veel gebruikte manier om deze wijzigingen te lokaal te verwerken, is door ze middels een merge naar je feature branch te halen. In dat geval maakt Git een merge-commit aan en komen de wijzigingen van de master terug in jouw eigen branch. Het nadeel van deze methode is dat de historie lastiger te lezen kan zijn vanwege de vele merge commits die op deze manier gedaan worden. Het voordeel is dat deze actie altijd veilig is, doordat bestaande branches en commits met rust worden gelaten.

Optie 2 voer een rebase uit van de master naar je feature branch

Een tweede manier om de wijzigingen van de master branch in je feature branch te krijgen, is met een rebase. In dit geval zal git je feature “oppakken” en de wijzigingen van de master voor je feature zetten. Het gevolg hiervan is dat de oude commits op de feature branch “stale” worden en dat er volledig nieuwe commits geschreven worden om de project historie te herschrijven. Het voordeel van deze manier van werken is een schonere historie in Git met minder merge-commits. Het belangrijkste nadeel is dat het herschrijven van de project historie een potentieel gevaarlijke actie is.

Risico bij het uitvoeren van een rebase

Zoals je in het bovenliggende plaatje ziet, zal een rebase je volledige branch “oppakken” en verplaatsen ten opzichte van de commits op de branch die je naar je feature rebaset. Maar stel dat je feature branch gepubliceerd is en dat er andere collega’s ook op werken. In dat geval is het werk wat beiden doen uit sync en is het heel lastig om dat weer recht te trekken. Gebruik daarom geen rebase op werk dat al naar een remote branch gepubliceerd is.

Wanneer gebruik je rebase en wanneer merge

Als je aan het werk bent aan een lokale feature die je wilt gaan afronden en in de tussentijd zijn er wijzigingen gedaan die je lokaal wilt verwerken, dan is een rebase een prima manier om deze wijzigingen te integreren. In de uiteindelijke historie geeft dat een mooier overzicht en omdat de wijzigingen toch enkel lokaal staan is er geen enkel risico. Is echter je branch gepubliceerd, dan is het niet verstandig een rebase uit te voeren en verwerk je eventuele wijzigingen met een merge.

Maar wat is nu een pull request?

Het voordeel van de epics en de features is dat je stories mooi kunt groeperen, het nadeel is dat de lijst niet langer noodzakelijk op volgorde van prioriteit staat omdat je in veel gevallen aan meerdere features parallel werkt. Ikzelf vind het belangrijk om een effectief praatplaatje te hebben om met stakeholders over de roadmap te kunnen praten. De laatste tijd heb ik hiervoor de feature timeline plugin gebruikt en ik ben hier erg over te spreken:

De plugin geeft een overzichtelijk scherm waarin de epics en de features uitgezet zijn in de tijd. In het verleden kwamen features alleen op de tijdlijn terecht door de onderliggende story planning. Inmiddels hebben ze dit gelukkig los gelaten waardoor je onafhankelijk van de stories de features op de tijdlijn kunt slepen en eventueel vergroten of verkleinen. Daarnaast geeft de plugin ook de voortgang van de onderliggende stories aan zodat ook tijdens de ontwikkeling het scherm een mooi overzicht van de voortgang blijft geven.

Hoe in te richten

De feature en epic timelines zijn niet standaard actief in Azure DevOps. Deze zul je via de marketplace moeten installeren.

Bij een standaard configuratie van Azure DevOps staan de epic navigation levels uit. In dat geval zul je deze eerst moeten inschakelen. Als epic niveau gebruik ik meestal de hoog-over doelstellingen van een kwartaal.

Waarom async/await een goede zaak is

Er zijn eigenlijk twee belangrijke redenen om async/await toe te passen. In webapplicaties zal de webserver (afhankelijk van de gekozen technologie) maar een beperkt aantal threads tegelijk in een workerprocess afhandelen. Dit betekent dat bij een groot aantal gelijktijdige verzoeken de webserver processen in de wacht gaat zetten. Door gebruik te maken van async/await, wordt de calling thread van het workerprocess vrijwel direct vrijgegeven, terwijl een background thread de bulk van het werk uitvoert. In client applicaties (Windows en apps) zijn asynchrone processen vooral van belang omdat de UI-thread wordt vrijgegeven en de applicatie dus goed blijft reageren op de gebruiker, terwijl processen op de achtergrond worden afgehandeld. Elke langlopende taak (database, I/O of zware berekening) leent zich om in een asynchrone taak af te handelen.

Valkuil 1: Deadlocks

In het voorbeeld hieronder wordt het resultaat van een taak uitgevraagd. Stel dat dit een asynchrone methode is, die zelf ook gebruik maakt van async/await, dan creëer je een deadlock. Dat komt omdat het aanroepen van Result, de UI-thread in de wacht zet totdat het resultaat van de methode terugkomt. Als de methode zelf een await commando gebruikt, zal deze een thread opstarten en na afloop het werk willen teruggeven aan de UI-thread. Dat kan echter niet omdat deze UI-thread aan het wachten is op het resultaat van de functie die hij nu zelf moet uitvoeren.

Ofschoon dit fenomeen vooral voor zal komen in een Windows applicatie of app, is het niet uit te sluiten dat deadlocks voorkomen in een webapplicatie; zeker wanneer je zelf de asynchrone taken beheert en niet gebruik maakt van de asynchrone controllers van ASP.NET.

Oplossing

Zorg dat de methode nadat deze gereed is, wordt opgevolgd door een nieuwe asynchrone taak die het resterende werk uitvoert. In de praktijk is het aan te raden om een class op te zetten die alle uitkomsten van een taak correct afhandelt, want er komt nogal wat bij kijken om alle foutafhandeling en cancellation scenario’s in te bouwen.

Valkuil 2: UI werk op een niet-UI-thread

In het voorbeeld hierboven werd het resultaat van een taak gebruikt in op een label de content te veranderen. Dit gaat fout in Windowsapplicaties en apps wanneer een andere thread dan de UI-thread deze code uitvoert.

Oplossing

Stuur het werk dat naar de UI-thread moet via de Dispatcher naar de UI-thread. Deze is toegankelijk vanaf een window/usercontrol of via het Application object. In de praktijk schijf ik hier altijd een proxy met interface voor, zodat ik de code ook kan unittesten. Let wel op, dat de code binnen de invoke ook eigen foutafhandeling heeft om te voorkomen dat fouten worden “ingeslikt” als ze plaatsvinden.

Valkuil 3: incorrecte/geen foutafhandeling

Binnen een async/await context worden fouten netjes doorgegeven aan de aanroepende thread. Wanneer je aan het einde van de call-chain aankomt, is het heel gemakkelijk om de foutafhandeling te vergeten.

Bovenstaande code zal zonder problemen draaien, maar indien er in de ExecuteAsync een fout plaatsvindt zal deze niet zichtbaar worden in de aanroepende thread. Gebruik om dezelfde reden geen async void (tenzij je zeker weet wat je doet), maar retourneer altijd een taak zodat eventuele fouten afgehandeld kunnen worden. Wanneer je de code aanpast naar ExecuteAsync().Wait() zal er wel een fout optreden, echter dan krijg je weer deadlock problemen.

Oplossing

Schrijf, zoals in een eerder voorbeeld, een juiste continuatie taak waarin eventuele fouten worden afgehandeld.

Schrijf wat er moet gebeuren wanneer er een fout optreedt (bij voorkeur wat charmanter dan MessageBox.Show).

Valkuil 4: await alleen als het nodig is

In het bovenstaande voorbeeld wordt de ReadFileAsync methode aangeroepen. De aanroepende methode zal bij het await keyword een nieuwe thread opstarten om het asynchrone werk op te pakken. De ReadFileAsync methode zal nogmaals een thread opstarten bij het await keyword. Deze laatste is onnodig omdat de waarde van ReadToEndAsync in deze methode niet gebruikt wordt. In dit geval is het beter om geen async/await te gebruiken, maar rechtstreeks een Task te retourneren.

Oplossing

Geef een taak terug zodat er slechts een thread opgestart wordt bij de eerste await. Let wel op dat je in dit geval de boundaries van de code goed in acht neemt. De using statements moeten hier binnen de taak liggen en niet erbuiten anders zijn deze objecten al opgeruimd terwijl de taak nog draait.

Valkuil 5: start niet onnodig threads op

Los van de zaken die in bovenstaande code niet juist zijn, zoals het niet afhandelen van fouten en onhandig aanmaken van de HttpClient, wordt er voor elke parallelle actie nu een extra thread gemaakt voor het uitvoeren van de post. Dat betekent een thread vanuit de task parallel library en een vanuit async/await.

Oplossing

Bij een groot aantal url’s is de beste oplossing om wel de task parallel library te gebruiken, maar hierbinnen de post synchroon te houden. Bij een klein aantal url’s kun je beter een lijst van taken retourneren waar je de code op laat wachten.

Bekijk ook de webinar die we vanuit ons Competence Center georganiseerd hebben:

Laat me dit toelichten door het DRY-principe erbij te halen:

Er zit in de principes van DRY een addertje onder het gras: DRY gaat niet over code maar over knowledge en daarmee over gedrag. Stel dat bijvoorbeeld binnen het systeem op verschillende plaatsen een agenda-afspraak gemaakt kan worden, dan is het essentieel al deze implementaties terugvallen op één enkele waarheid. Doe je dit niet, dan zal een systeem snel onduidelijke business rules hebben met instabiliteit voor de toepassing en onduidelijkheid voor de ontwikkelaars als gevolg.

Waarom is het nu zo’n probleem wanneer dit principe ongecompliceerd wordt toegepast op code? Omdat dit kan betekenen dat twee niet gerelateerde stukken code ineens een gezamenlijke codebase delen. Stel bijvoorbeeld dat een programma zowel ordermanagement als inventory management bevat:

Op basis van de bovenstaande code zou je tot de conclusie kunnen komen dat er twee identieke classes product in de toepassing zitten, en zou je deze tot één class kunnen terugbrengen. De classes representeren echter heel ander gedrag, met andere business transacties en rules. De kans dat de classes zich in de toekomst anders ontwikkelen is heel groot. Wanneer je dus deze beide classes tot één class maakt vanuit het DRY-principe creëer je een tight coupling tussen twee niet gerelateerde domeinen in de software en overtreedt je code het logische model van je applicatie.

In dit voorbeeld is het misschien voor de hand liggend dat je niet kiest voor één class, maar in de praktijk zijn er legio subtielere voorbeelden te bedenken waarbij ontwikkelaars code fragmenten hebben ondergebracht in utility bibliotheken om vervolgens met allerlei kunstgrepen de code op één plek te houden. Wanneer je binnen je code een switch nodig hebt om op basis van een type ander gedrag te selecteren, dan had deze code waarschijnlijk nooit op één plek mogen zitten.

Wat richtlijnen voor de praktijk:

Bepaal code replicatie op basis van gedrag en domein en niet op basis van de code