.NET en React voor enterprise software: team en valkuilen

Een .NET-backend met een React-frontend is een goede combinatie voor enterprise software. C# en ASP.NET Core geven je een getypeerde, volwassen backend met een voorspelbare releasecyclus, en voor React vind je veel developers. De risico's zitten vooral op de grens tussen die twee: types die uit elkaar lopen, twee builds die los van elkaar live gaan en een team dat in een backend- en een frontendkamp uiteenvalt.

Wat .NET goed doet in de backend

Enterprise software heeft veel bedrijfsregels en koppelingen met andere systemen, en gaat jaren mee. Daar past C# bij: sterke types, goede tooling en een framework dat authenticatie, autorisatie, dependency injection en logging standaard meelevert. ASP.NET Core is open source en cross-platform, dus je draait het zonder problemen in Linux-containers.

Microsoft brengt elk jaar in november een nieuwe .NET-versie uit. LTS-versies zoals .NET 8 en .NET 10 krijgen drie jaar ondersteuning. STS-versies krijgen sinds .NET 9 twee jaar in plaats van achttien maanden. Dat maakt upgrades planbaar, als je ze ook inplant.

Voor .NET 8 en .NET 9 is dat nu dringend, want die krijgen na 10 november 2026 geen beveiligingsupdates meer. Draait een van je services daar nog op, zet de overstap naar .NET 10 dan deze sprint op het bord. .NET 10 wordt ondersteund tot november 2028.

Wat React doet in de frontend

Voor interne applicaties achter een login heb je meestal geen server rendering nodig. Een React-app met Vite en TypeScript die de API aanroept, is dan het eenvoudigst om te bouwen en te hosten. Heb je ook publieke pagina's die goed gevonden moeten worden in Google, dan is Next.js de betere keuze voor dat deel.

Houd de frontend zo eenvoudig mogelijk. Validatie en rechten horen in de backend; de frontend toont wat de API teruggeeft en stuurt door wat de gebruiker invult. Dan hoef je bedrijfsregels maar op één plek te testen.

Het teamprofiel

Mijn advies is om geen apart backendteam en frontendteam te maken. Features blijven dan hangen op de grens, omdat de ene groep op de andere wacht. Laat liever één developer een feature bouwen van API tot scherm, en zorg dat het team als geheel beide kanten goed beheerst.

Voor een team van vier of vijf developers zou ik zoeken naar:

• C#-developers die ook prima met React en TypeScript overweg kunnen;
• minstens één developer die sterk is in frontend, voor de componentenbibliotheek, toegankelijkheid en prestaties;
• iemand die de database en Entity Framework Core door en door kent.

Bij het screenen zou ik C#-developers vragen naar async/await, naar wat Entity Framework van hun LINQ-query maakt en hoe ze een N+1-probleem herkennen. Frontendkandidaten krijgen vragen over state, formulieren en TypeScript-types. Wat zo'n team kost, staat op de pagina over een remote team opbouwen.

Valkuilen op de grens tussen backend en frontend

De bekendste valkuil is dat je types twee keer bijhoudt. C#-DTO's en TypeScript-interfaces die iemand met de hand overtypt, lopen binnen een paar maanden uit elkaar. ASP.NET Core genereert zelf een OpenAPI-document met het pakket Microsoft.AspNetCore.OpenApi, en met Microsoft.Extensions.ApiDescription.Server ook tijdens de build. Maak daar in CI TypeScript-types of een complete client van, en laat de build falen als het gegenereerde bestand afwijkt van wat in git staat.

Verder gaan frontend en backend vaak via twee pipelines live. Een frontend die een API-versie verwacht die nog niet draait, geeft fouten die lastig te vinden zijn. Bouw en test beide in één pipeline. Of serveer de gebouwde React-app als statische bestanden vanuit de API, dan gaan ze altijd samen live.

Draait de React-app op hetzelfde domein als de API, gebruik dan httpOnly-cookies om in te loggen en geen tokens in localStorage. De backend beheert de sessie en de frontend krijgt alleen wat die nodig heeft.

Het laatste risico is Entity Framework zonder toezicht. EF Core maakt het makkelijk om ongemerkt per regel in een lijst een extra query te doen. Log in development de SQL die EF Core genereert en kijk ernaar bij code review.

Infrastructuur en kosten

ASP.NET Core draait in een Linux-container, dus je kunt hosten op Azure, op een andere cloud of op eigen servers. Voor de database is SQL Server de gebruikelijke keuze in een Microsoft-omgeving. Voor een nieuw project zou ik ook naar Postgres kijken, want Entity Framework Core ondersteunt het via de Npgsql-provider. Neem de licentiekosten van SQL Server mee in die afweging. Waarom ik voor nieuwe projecten bij Postgres begin, staat in Postgres als standaard database.

We bouwen zelf ook met deze stack. Voor Nannies at Night bouwden we een platform met een .NET-backend, een React-frontend en Postgres, met matching, planning en betalingen in één systeem.

Wanneer een andere stack beter past

Een klein team dat alleen TypeScript schrijft en een webproduct bouwt, is sneller met één taal aan beide kanten. Heb je een bestaande .NET Framework-applicatie, dan is de eerste stap een migratieplan en geen nieuwe frontend. Begin dan met de onderdelen die het vaakst veranderen en laat de rest voorlopig staan.

Bronnen

• .NET Blog: .NET 8 and .NET 9 end of support
• Microsoft Learn: Overview of ASP.NET Core
• Microsoft Learn: Overview of OpenAPI support in ASP.NET Core API apps
• Microsoft Learn: EF Core database providers