Wann ein Monorepo Frontend und Backend zusammenführt
Monorepos polarisieren. Die einen schwören drauf, weil sie Frontend und Backend in einem Repo halten und Schemas teilen können. Die anderen verfluchen sie, weil sie unhandlich werden, sobald die Teams wachsen. Beide Lager liegen meistens falsch, weil sie pauschal argumentieren.
Die ehrlichere Antwort: Ein Monorepo ist sinnvoll, wenn drei Bedingungen erfüllt sind. Sonst nicht.
Bedingung 1: Frontend und Backend werden zusammen entwickelt
Wenn eine Änderung im Backend regelmäßig eine Änderung im Frontend erfordert (oder umgekehrt), ist ein Monorepo praktisch. Beide Änderungen passieren in einem Pull Request, beide werden zusammen reviewt, beide gehen zusammen live.
Bei getrennten Teams, die unabhängig releasen, ist das Gegenteil wahr. Da bremst ein Monorepo, weil ein Team Änderungen mergen müsste, die das andere noch nicht braucht.
Die Frage ist nicht, ob ein Monorepo elegant aussieht. Die Frage ist, ob eure Änderungen tatsächlich gekoppelt entstehen.
Bedingung 2: Es gibt geteilten Code
Wenn Frontend und Backend ein Schema teilen (TypeScript-Interfaces, Validierungs-Regeln, Shared Constants), ist ein Monorepo der ruhigere Weg. Das Schema liegt in einem Paket, das beide Seiten importieren. Ein einziger Ort für die Wahrheit.
Ohne geteilten Code verliert das Monorepo einen seiner Hauptvorteile. Dann sind getrennte Repos genauso gut, oft sogar besser, weil Build-Pipelines simpler bleiben.
Bedingung 3: Das Tooling skaliert
Monorepos brauchen mehr Tooling als getrennte Repos. Build-Caching (Turbo, Nx, Bazel), saubere Abhängigkeits-Definitionen, geschickte CI/CD-Pipelines, die nur betroffene Teile bauen. Wenn euer Team bereit ist, in dieses Tooling zu investieren, läuft das Monorepo entspannt. Wenn nicht, wird der CI-Build mit jedem Commit länger und der gefühlte Aufwand steigt.
Was viele falsch machen
Ein Monorepo wird eingeführt, weil “alle es jetzt machen”, ohne die drei Bedingungen zu prüfen. Nach sechs Monaten sind Frontend und Backend in einem Repo, aber sie werden weiterhin von getrennten Teams unabhängig entwickelt. Sie teilen keinen Code. Das Tooling ist nicht eingerichtet. Das einzige, was sich verändert hat, ist dass Pull Requests länger dauern.
Das ist der schlimmste aller Fälle: alle Nachteile, kein Vorteil.
Fazit
Ein Monorepo ist keine Mode, sondern eine Antwort auf eine bestimmte Konstellation. Wer prüfen will, ob die eigene Konstellation passt, kann mich gerne ansprechen.