Eine Website in abschaltbare Module zerlegen

Diese Website besteht aus Modulen. Der Blog, den Sie gerade lesen, das LiDAR-Labor, der Karrierebereich, sogar das Kontaktformular — jedes ist eine in sich geschlossene Einheit, die sich im laufenden Betrieb ein- und ausschalten lässt, ohne Rebuild oder Redeploy.

Warum der Aufwand?

Weil Websites nie fertig sind. Bereiche starten halbfertig, Kampagnen enden, Experimente scheitern. Die übliche Antwort ist ein Feature-Branch und ein Deployment; unsere ist ein Schalter. Und wenn wir diese Codebasis für eine andere Website wiederverwenden, starten wir mit demselben Katalog und aktivieren einfach eine andere Teilmenge.

Anatomie eines Moduls

Jedes Modul wird durch ein kleines Manifest beschrieben: eine ID, die Routen, die ihm gehören, und sein Navigationseintrag. Aus dieser einen Quelle leiten wir alles Weitere ab:

• Der Proxy (Next.js-Middleware) prüft jede Anfrage gegen die Routen deaktivierter Module und antwortet mit 404 — dadurch greifen Schalter sofort, selbst bei statisch vorgerenderten Seiten.
• Ein Route-Guard im Layout des Moduls bildet die zweite Verteidigungslinie in der App.
• Header, Footer und Befehlspalette filtern ihre Links über dieselbe Menge aktiver Module, clientseitig aktualisiert.

Drei Konfigurationsebenen

Die aktive Modulmenge wird über drei Ebenen aufgelöst, spätere gewinnen: eingecheckte Defaults, Umgebungsvariablen pro Deployment und eine Laufzeit-Override-Datei, die ein token-geschütztes Admin-Panel schreibt. Kernmodule — Startseite, Rechtliches — lassen sich auf keiner Ebene deaktivieren.

Der ehrliche Kompromiss

Die Infrastruktur kostet Indirektion: Ein neuer Bereich muss ein Manifest registrieren, statt nur eine Seite hinzuzufügen. Dafür wird aus „Können wir den Bereich vorerst ausblenden?" eine Antwort von zehn Sekunden statt eines Deployments. Für ein Studio, das viele kleine Websites betreibt, rechnet sich dieser Tausch schnell.