Next.js + PostgreSQL + AWS: Der Stack, den wir für interne Geschäftsplattformen nutzen, und warum

Wir sind nicht bei Next.js, PostgreSQL und AWS gelandet, indem wir Trends hinterherliefen, wir sind dort gelandet, weil es konsequent zur Form interner Geschäftsplattformen passt: eine Mischung aus authentifizierten Dashboards, strukturierten relationalen Daten und Integrationspunkten mit anderen Systemen, die ein Unternehmen bereits betreibt. Hier ist die tatsächliche Begründung pro Schicht, und wo wir bewusst etwas anderes wählen würden.

Next.js verdient sich seinen Platz eher durch Rendering-Flexibilität als durch React selbst. Interne Plattformen sind selten nur eine Art von Seite; oft gibt es einen öffentlich zugänglichen Teil (eine Login-Seite, vielleicht einen Marketing-Einstiegspunkt) neben authentifizierten Dashboards mit nutzerspezifischen Daten. Das Rendering pro Route von Next.js, statisch wo sich Inhalt nicht pro Request ändert, server- oder client-gerendert wo doch, lässt eine einzelne Anwendung beides handhaben, ohne eine Alles-oder-nichts-Architekturentscheidung zu erzwingen.

PostgreSQL ist der Standard aus demselben Grund, aus dem es seit zwei Jahrzehnten der Standard ist: Interne Geschäftsdaten sind meist wirklich relational, Kunden beziehen sich auf Bestellungen, die sich auf Positionen beziehen, die sich auf Produkte beziehen, und eine ausgereifte relationale Datenbank mit starken Konsistenzgarantien passt zu dieser Form besser, als standardmäßig zu etwas Schemalosem zu greifen. Ihre Reife zählt auch operativ: gut verstandene Backup-, Migrations- und Performance-Tuning-Praktiken, die keine Wette auf das noch entwickelnde Tooling einer neueren Datenbank erfordern.

AWS verdient sich seinen Platz durch zwei Dinge: Infrastrukturkontrolle und Servicebreite. Eine Plattform, die einfach beginnt, eine Web-App, eine Datenbank, muss manchmal in Hintergrund-Jobverarbeitung, Dateispeicherung, geplante Aufgaben oder Infrastruktur hineinwachsen, die eine einfachere PaaS nicht bietet. Infrastruktur zu wählen, die in diese Bedürfnisse hineinwachsen kann, ohne eine Plattformmigration, vermeidet später ein kostspieliges Re-Platforming-Projekt, selbst wenn die frühe Version des Systems wirklich einfach ist.

TypeScript über den gesamten Stack hinweg, nicht nur im Frontend, ist es, was diese Kombination in der Praxis tatsächlich gut zusammenhält. Geteilte Typen zwischen dem Next.js-Frontend, der API-Schicht und dem Datenmodell reduzieren eine ganze Kategorie von Fehlern, Frontend und Backend, die über die Form eines Feldes uneinig sind, die in einem gemischtsprachigen Stack echte Debugging-Zeit kostet.

Das ist kein Stack, zu dem wir unabhängig vom Projekt standardmäßig greifen. Ein kleines internes Skript, das einmal pro Woche läuft, braucht kein volles Web-Framework. Eine weitgehend statische Content-Website braucht keine relationale Datenbank oder die volle Servicebreite von AWS; ein einfacheres Hosting erledigt diesen Job mit weniger operativem Aufwand. Der Stack passt zu internen Plattformen mit echter, wachsender Komplexität, nicht zu jedem Projekt, das zufällig eine Web-Oberfläche braucht.

Wo wir anders wählen würden: Ein Team, das bereits tief in Vue versiert ist, greift aus denselben zugrunde liegenden Gründen zu Nuxt statt Next.js, nicht weil Next.js objektiv besser ist. Ein Projekt mit wirklich einfachen, dokumentförmigen Daten (nicht relational) passt vielleicht besser zu einer anderen Datenbank. Und ein Projekt mit engen Budgetgrenzen und bescheidenen Infrastrukturbedürfnissen braucht die Breite von AWS vielleicht gar nicht. Der Stack folgt der tatsächlichen Form des Projekts, nicht umgekehrt.

Was wir mit dieser Kombination tatsächlich optimieren, ist eine Plattform, die einfach beginnen und ohne Neuaufbau wachsen kann: Rendering-Flexibilität, die von einer Marketing-Seite bis zu einem komplexen Dashboard skaliert, ein Datenmodell, das standhält, während Beziehungen komplexer werden, und Infrastruktur mit Spielraum für alles, was die Plattform als Nächstes braucht. Das ist das Argument für Next.js, PostgreSQL und AWS, nicht dass es von Natur aus korrekt ist, sondern dass es sich Projekt für Projekt bewährt hat, während sich die Form „interne Geschäftsplattform" wiederholt.