Drei Flächen, ein Deployment
Website, Kundenbereich und Verwaltung laufen aus einem einzigen Worker — was das spart und wo die Grenze liegt.
merkinity.com ist die öffentliche Website. hub.merkinity.com ist der Bereich, in dem Kunden den Stand ihres Projekts sehen. admin.merkinity.com ist die Verwaltung. Drei Adressen, drei sehr verschiedene Aufgaben — und ein einziges Deployment.
Der naheliegende Weg und was gegen ihn spricht
Üblich wäre, daraus drei Anwendungen zu machen. Jede hat ihren eigenen Quelltext, ihre eigene Auslieferung, ihre eigene Konfiguration. Das klingt sauber und hat einen unangenehmen Preis: Alles, was alle drei gemeinsam haben, existiert dreimal.
Bei Merkinity ist das mehr, als man zunächst denkt. Die Farben und Schriften sind dieselben. Die Anmeldung ist dieselbe. Die Datenbankanbindung, die Typen, die Datumsformate, die Fehlermeldungen — alles dasselbe. Bei drei Anwendungen bedeutet jede Änderung daran drei Änderungen, und nach einem halben Jahr sind es drei verschiedene Stände.
Die Entscheidung fällt am Hostnamen
Stattdessen bedient ein Worker alle drei Adressen. Welche Fläche gerendert wird, entscheidet der Host-Header der Anfrage — nicht ein Pfadpräfix wie /hub und nicht eine Umgebungsvariable.
Das ist ein wichtiger Unterschied. Ein Pfadpräfix hieße, dass der Kundenbereich unter merkinity.com/hub läge — mit derselben Herkunft wie die öffentliche Seite. Jedes Skript, das auf der Website läuft, könnte dann auf die Daten im Kundenbereich zugreifen. Getrennte Subdomains sind getrennte Herkünfte, und der Browser setzt diese Trennung durch, ohne dass jemand daran denken muss.
In der Entwicklung wäre das lästig — lokal gibt es keine Subdomains. Deshalb schlägt dort ein Parameter in der Adresse die Erkennung: ?surface=admin zeigt die Verwaltung, ?surface=hub den Kundenbereich. Das gilt ausschließlich für localhost; in der Produktion entscheidet allein der Hostname.
Was dabei zusammenbleibt und was nicht
Gemeinsam sind: Gestaltung, Anmeldung, Datenmodell, Hilfsfunktionen, Bauteile. Getrennt sind: was jede Fläche zeigt, und wer sie sehen darf.
Die zweite Trennung liegt nicht in der Anwendung, sondern in der Datenbank. Jede Tabelle hat Zugriffsregeln, die auf Zeilenebene entscheiden: Ein Betreiber sieht alle Projekte, ein Kunde nur seine eigenen. Die Anwendung stellt dieselbe Abfrage — zurück kommt Verschiedenes.
Das ist der eigentliche Grund, warum ein gemeinsames Deployment hier vertretbar ist. Würde die Trennung in der Anwendung stattfinden, wäre jeder vergessene Filter ein Datenleck. So ist ein vergessener Filter eine leere Liste.
Was das kostet
Ein gemeinsames Bündel ist größer als drei kleine. Wer die öffentliche Website öffnet, lädt nicht den Quelltext der Verwaltung — dafür sorgt die Aufteilung nach Routen —, aber die gemeinsamen Teile sind in jedem Fall dabei.
In Zahlen: Die Startseite lädt rund 90 KB an JavaScript, komprimiert. Bei drei getrennten Anwendungen wären es vielleicht 75. Die Differenz ist messbar und in der Praxis bedeutungslos — sie entspricht etwa einem mittelgroßen Foto.
Der zweite Preis ist unangenehmer: Ein Fehler im gemeinsamen Teil trifft alle drei Flächen. Wenn die Anmeldung kaputt ist, ist sie in beiden Bereichen kaputt. Das ist der Grund, warum die gemeinsamen Teile die dichtesten Tests haben.
Wo die Grenze liegt
Dieser Aufbau trägt, solange die drei Flächen dieselbe Welt beschreiben — dieselben Kunden, dieselben Projekte, dieselbe Gestaltung. Er würde nicht mehr tragen, wenn eine der Flächen einen eigenen Rhythmus bekäme: einen eigenen Veröffentlichungsplan, ein eigenes Team, eine eigene Datenbank.
Dann wäre die Trennung nicht mehr eine Frage der Technik, sondern der Organisation — und Technik, die gegen die Organisation arbeitet, verliert immer.
Für einen Einzelunternehmer mit einer Handvoll Projekten ist das noch weit weg. Aber es ist der Punkt, an dem ich noch einmal nachdenken würde, und es ist besser, ihn vorher zu kennen als hinterher.
