Next.js + PostgreSQL + AWS: de stack die we gebruiken voor interne bedrijfsplatforms, en waarom

We zijn niet bij Next.js, PostgreSQL en AWS uitgekomen door trends achterna te jagen, we zijn erbij uitgekomen omdat het consistent past bij de vorm van interne bedrijfsplatforms: een mix van geauthenticeerde dashboards, gestructureerde relationele data, en integratiepunten met andere systemen die een bedrijf al draait. Dit is de daadwerkelijke redenering per laag, en waar we juist bewust voor iets anders zouden kiezen.

Next.js verdient zijn plek meer op renderingflexibiliteit dan op React zelf. Interne platforms zijn zelden één soort pagina; er is vaak een publiek gerichte kant (een inlogpagina, misschien een marketing-entreepunt) naast geauthenticeerde dashboards met data per gebruiker. De rendering per route van Next.js, statisch waar content niet per verzoek verandert, server-rendered of client-rendered waar dat wel zo is, laat één applicatie beide afhandelen zonder een alles-of-niets-architectuurbeslissing af te dwingen.

PostgreSQL is de standaard om dezelfde reden dat het al twee decennia de standaard is: interne bedrijfsdata is meestal oprecht relationeel, klanten relateren aan bestellingen relateren aan orderregels relateren aan producten, en een volwassen relationele database met sterke consistentiegaranties past beter bij die vorm dan standaard iets schemaloos te pakken. De volwassenheid doet er ook operationeel toe: goed begrepen back-up-, migratie- en performance-tuningpraktijken die niet vereisen dat je gokt op de nog in ontwikkeling zijnde tooling van een nieuwere database.

AWS verdient zijn plek op twee dingen: infrastructuurcontrole en breedte aan diensten. Een platform dat eenvoudig begint, een webapp, een database, moet soms uitgroeien naar achtergrondtaakverwerking, bestandsopslag, geplande taken, of infrastructuur die een eenvoudigere PaaS niet biedt. Infrastructuur kiezen die kan uitgroeien naar die behoeften zonder een platformmigratie voorkomt een kostbaar herplatformingsproject later, zelfs wanneer de vroege versie van het systeem oprecht eenvoudig is.

TypeScript door de hele stack heen, niet alleen de frontend, is wat deze combinatie in de praktijk daadwerkelijk goed laat samenhangen. Gedeelde types tussen de Next.js-frontend, de API-laag en het datamodel verminderen een hele categorie bugs, de frontend en backend die het oneens zijn over de vorm van een veld, wat in een gemengdtalige stack echte debugtijd kost.

Dit is geen stack waar we standaard naar grijpen ongeacht het project. Een klein intern script dat één keer per week draait heeft geen volledig webframework nodig. Een grotendeels statische contentsite heeft geen relationele database of de volledige dienstenbreedte van AWS nodig; een eenvoudigere host doet die klus met minder operationele overhead. De stack past bij interne platforms met echte, groeiende complexiteit, niet elk project dat toevallig een webinterface nodig heeft.

Waar we anders zouden kiezen: een team dat al diep vertrouwd is met Vue grijpt naar Nuxt in plaats van Next.js om dezelfde onderliggende redenen, niet omdat Next.js objectief beter is. Een project met oprecht eenvoudige, documentvormige data (niet relationeel) past mogelijk beter bij een andere database. En een project met krappe budgetbeperkingen en bescheiden infrastructuurbehoeften heeft de breedte van AWS misschien helemaal niet nodig. De stack volgt de daadwerkelijke vorm van het project, niet andersom.

Wat we met deze combinatie daadwerkelijk optimaliseren is een platform dat eenvoudig kan beginnen en groeien zonder herbouw: renderingflexibiliteit die schaalt van een marketingpagina naar een complex dashboard, een datamodel dat standhoudt naarmate relaties complexer worden, en infrastructuur met speelruimte voor wat het platform hierna ook nodig heeft. Dat is het argument voor Next.js, PostgreSQL en AWS, niet dat het inherent correct is, maar dat het project na project heeft standgehouden omdat de vorm van "intern bedrijfsplatform" zich herhaalt.