Wer in einer kleinen Struktur viele Systeme betreibt, kann sich keine fünf Technologien leisten. Jede zusätzliche bedeutet ein zweites Vorgehen beim Bauen, beim Ausrollen, beim Absichern und beim Reparieren um drei Uhr nachts.
Bei uns läuft deshalb fast alles auf derselben Grundlage: Next.js in der jeweils aktuellen Fassung, gerade 16.3. Agenturseite, Kundenportal, Pixel-Projekt, Kundenseiten. Hier steht, warum.
Eine Sprache für Oberfläche und Server
Der größte Gewinn ist nicht technisch, sondern menschlich. Eine Seite, ein Formular, die Verarbeitung dahinter und der Zugriff auf die Datenbank liegen in derselben Sprache und oft in derselben Datei. Niemand muss zwischen zwei Welten übersetzen, und es gibt keine Schnittstelle, die es nur gibt, weil die Technik getrennt ist.
Für einen Betrieb heißt das: weniger Stellen, an denen Wissen verloren geht.
Schnell, ohne dass jemand nachhelfen muss
Seiten, die sich selten ändern, werden beim Bauen erzeugt und liegen fertig da. Seiten mit Daten werden auf dem Server gerendert und kommen mit den richtigen Inhalten an. Bilder werden in die passende Größe und Form gebracht, ohne dass jemand daran denkt.
Das ist genau die Art Arbeit, die niemand sieht und die über Ladezeit und Sichtbarkeit entscheidet.
Was wir konkret davon haben
- Ein Befehl für alles. Bauen, Container tauschen, prüfen, im Zweifel zurück auf die vorige Fassung. Bei uns dauert der Tausch zwei Sekunden.
- Gleiche Bauart in jedem Projekt. Wer das Kundenportal kennt, findet sich im Pixel-Projekt zurecht.
- Server-Aktionen statt eigener Schnittstellen. Ein Formular schreibt direkt in die Datenbank, ohne dass wir dafür eine API bauen, die niemand sonst braucht.
- Bilder und Vorschauen als Teil der Anwendung. Unsere Story-Poster für den Blog entstehen in derselben Anwendung, aus denselben Daten.
- Standalone-Bauweise. Das Ergebnis ist ein schlanker Container, der ohne Entwicklungswerkzeuge läuft, mit engen Rechten und eigenem Speicherdeckel.
Warum wir die aktuelle Fassung fahren
Ältere Fassungen sind bequem und werden mit der Zeit teuer. Sicherheitslücken werden dort zuerst geschlossen, wo die Entwicklung stattfindet. Wer zwei Jahre wartet, macht aus einem kleinen Schritt einen Umbau.
Wir aktualisieren deshalb regelmäßig und halten drei Regeln ein:
- Erst in einem eigenen Arbeitsbaum bauen, nie direkt im laufenden Stand.
- Das Bauverzeichnis und der laufende Dienst tragen dieselbe Fassung. Wer das trennt, bekommt Fehler, die niemand nachvollziehen kann.
- Vor dem Tausch eine Sicherung, nach dem Tausch eine Prüfung, und ein Rückweg, der wirklich getestet ist.
Wo die Grenzen liegen
Next.js ist kein Allheilmittel.
- Für lange Rechenarbeit im Hintergrund nehmen wir einen eigenen Arbeiter mit Warteschlange, nicht die Webanwendung.
- Für dauerhafte Verbindungen, etwa die lebende Wand im Pixel-Projekt, läuft ein eigener Dienst daneben.
- Für Systeme, die wir übernommen haben, bleibt die vorhandene Technik bestehen, solange sie trägt. Man baut nichts um, nur weil es anders aussieht.
Wenn du selbst vor der Wahl stehst
Die Frage ist selten, welche Technik die beste ist. Die Frage ist, welche du in zwei Jahren noch betreiben kannst, ohne dass jemand kündigt oder der Dienstleister wechselt.
Drei Punkte helfen bei der Entscheidung: Findest du Leute dafür. Bekommst du Sicherheitsaktualisierungen. Kannst du damit sowohl eine einfache Seite als auch ein Portal bauen.
Bei uns beantwortet Next.js alle drei mit ja. Das ist der ganze Grund.
