# The Resurgence of Monorepos in the AI Era

**Podcast:** Engineering Kiosk
**Published:** 2026-04-14

## Transcript

Willkommen zu einer neuen Episode vom Engineering Kios Podcast.
Heute geht es um ein Thema, das viele schon mal abgeschrieben hatten und das gerade ziemlich spannend zurück auf die Bühne kommt.
Monorepos.
War das Ganze nur ein Hype aus der Google-Ecke?
Oder ist genau jetzt der richtige Zeitpunkt, sich das Thema nochmal ernsthaft anzuschauen?
Dafür haben wir Max Kles zu Gast.
Er ist Senior Software Engineer bei NX und beschäftigt sich beruflich genau mit der Frage, wie Monorepos in der Praxis funktionieren, wo die Vorteile liegen, wo es weh tut und warum das richtige Tooling am Ende doch den Unterschied macht.
Wir sprechen darüber, was ein Monorepo überhaupt ist, warum Monorepo nicht gleich Monorepo ist und weshalb der Mittelweg für viele Teams sinnvoller sein kann als das eine gigantische Firmenrepository.
Außerdem geht es um Tooling, Project Graphs, Caching, CI, Ownership, Kultur und die Frage, warum Monorepos eben nicht nur ein technisches, sondern ab und zu auch ein organisatorisches Thema sind.
Und dann kommt noch der Klassiker, von dem wir irgendwie alle schon die Schnauze voll haben.
Aber wir müssen Ihnen mit reinbringen, welche Rolle spielen eigentlich AI, LLMs und Coding Agents dabei.
Ist das vielleicht genau der Grund, warum Monorepos gerade wieder deutlich relevanter werden?
Wer weiß das schon.
Wenn du dich schon mal über Releases abgestimmte Änderungen zwischen Frontend und Backend oder nervige Repo-Grenzen geärgert hast, dann ist diese Episode für dich.
Wir legen los.
Viel Spaß.
Der Andi beschimpft mich ja immer, dass ich irgendwie Geschichten aus dem Krieg erzähle, die irgendwie lange her sind.
Ich bin ja vermutlich auch heute in unserer illustren Runde der älteste.
Und wenn ich mich so zurückerinnere, wenn ich denn das Wort Monorepo höre, dann denke ich an so eine Zeit zurück, wo das der absolute Hype war.
Jeder wollte Monorepo machen, weil Google Monorepos gemacht hat und jeder wollte auf den Zug aufspringen.
Und es war wirklich gehypt.
In jedem zweiten Talk hast du was von Monorepos gehört.
Und wenn man sich dann angesehen hat, wie so die Umsetzung war, dann war das schon ziemlich schwierig und irgendwie ging der Hype relativ schnell vorbei, weil man gesehen hat, okay, man brauchte schon ziemlich gutes Tooling herum, damit das alles sinnvoll funktioniert und vielleicht ist es für Google gut, aber für viele andere nicht.
Und für mich persönlich ist es so ein bisschen eingeschlafen, das Thema.
Also das war dann so die letzten, würde man sagen, zehn Jahre war es nicht mehr so gehypt oder eigentlich nicht mehr so am Schirm.
Und in letzter Zeit ist mir persönlich auch wieder irgendwie untergekommen, weil mit dem ganzen AI und LLM-Trend habe ich auch persönlich gemerkt, dass es teilweise einfach einfacher ist, wenn man verschiedene Projekte gemeinsam in einem Repo hat und das LLM einfach über alles drüber fägen kann.
Und da habe ich mir wieder gedacht, okay, Monorepos, vielleicht ist es jetzt wieder ein Thema, vielleicht gibt es ja Tooling.
Und genau aus diesem Grund haben wir uns überlegt, okay, wir machen mal eine Episode zu dem ganzen Thema.
Wo stehen wir denn jetzt gerade?
Was funktioniert, was funktioniert nicht?
Und ist jetzt vielleicht die richtige Zeit für Monorepos?
Oder habe ich nur einfach geschlafen und habe nichts mitbekommen und eigentlich ist es eh überall schon ein großes Thema.
Und genau das besprechen wir heute.
Und da haben wir jemanden heute bei uns im Engineering Ciosk Studio, der uns da wesentlich mehr darüber erzählen kann.
Und daher, Max, willkommen bei unserem Engineering Kiosk Studio.
Hi, vielen Dank für die Einladung.
Das ist schön, dass ich hier sein kann mit euch.
Nach dem Intro habe ich so viele Fragen.
Erstens, die Story, die du gerade erzählt hast.
Also wer ich mir ja stammt die.
Du meinst, wann der Hype war?
Wann du den Hype so wahrgenommen hast?
Sagen wir es mal so.
Ich würde sagen, der Hype war so vor über zehn Jahren.
Da ist das so ziemlich gehypt worden, würde ich jetzt mal so einschätzen.
2016, ja, so ungefähr.
Zweite Frage.
Warst du dann immer der Typ, der rumgelaufen ist mit diesem Lehrerstock aus den 60ern, als man noch die Schüler verprügelt hat und hab gesagt, du sollst keine Monorepos nutzen, du bist nicht Google.
Ich komme ja aus Tiroli, verwende keine Stöcke, mehr so Eispixel und so, die verwendet für solche Zwecke.
Das ist also eine Zustimmung, das würde ich als Ja deklarieren.
Und die dritte Thematik, du sagtest, der Hype ist vorbei.
Ernsthaft.
Na, ich habe gesagt, der ist eingeschlafen, hat dieses Gefühl.
Es war nicht mal so bei jeder Konferenz ein großes Thema und irgendwie hat man sich darauf geeinigt, ja, okay, es ist einfach schwierig, wir machen es doch nicht so in die Richtung.
Also, normalerweise bei jedem würde ich sagen, unter welchem Stein lebst du denn?
Bei dir würde ich sagen, bei dir weht der Wind so ein bisschen falsch.
Innsbruck in eurem Tal da, weißt du, da geht der Wind schön über die Berge und irgendwie berührt das Tal nicht.
Kollege Schnürschuh, ich glaube, der Hype war nie weg.
Ich glaube, der war so ein konstanter Hype, die ganze Zeit dabei.
Und ich glaube, du lebst einfach nur in einem falschen Bubble.
Naja, ich würde einfach sagen, wenn es mich nicht mehr erreicht unter meinem Stein, dann ist der Hype vorbei.
Ja, ja, naja.
Man sieht das anders.
Aber Max, jetzt ist natürlich die Frage, wer ist dieser Max und warum kann dieser Max was über Monorepos erzählen?
Und da möchte ich ganz kurz erklären, wo der Max einfach mal herkommt.
Und zwar hat ich irgendwann mal Lust, lass uns mal eine Episode über Monorepos machen.
Also, was macht man bei?
Gib mein Google Monorepos ein?
Ja, nicht bei ChatGPT und auch nicht bei Claude, sondern einfach bei ganz oldschool Google.
Und einer der ersten Webseite ist Monorepo.tools.
Monorepo.tools ist, wer hätte es sich gedacht, eine Webseite über Tools zum Thema Monorepos.
Und everything you need to know about Monorepos and the Tools to Build Sim.
Wundervoll.
Dann bin ich da so ein bisschen rumgescrolt und irgendwann bin ich in den Footer gekommen und da steht, dass diese Webseite eine Webseite der Firma NX ist.
Und dann, was mache ich dann?
Ich schaue mir natürlich die Webseite von NX an.
NX ist eine Firma, die stellt eine Monorepo-Plattform zur Verfügung, würde ich mal sagen, mit Tooling drumherum und allem Pippapo.
Und dann bin ich auf jemanden gestoßen, der bei NX arbeitet, der aus Südtirol kommt.
Habe ich mir natürlich die Frage gestellt, okay, kann diese Person dann jetzt irgendwie Deutsch oder Italienisch oder irgendwie so ein Südtiroler-Dialekt.
Das ist ja noch schlimmer, als wenn der Wolfgang anfängt zu sprechen.
So, und da habe ich gedacht, okay, komm, ich gucke einfach mal weiter und da habe ich da gar nicht angefragt.
Und irgendwann bin ich über den Max gestolpert, denn der Max kommt nämlich aus München.
Das hat mich dann sehr gefreut.
Passend zum Engineering Kiosk ist der Max auch noch Senior Software Engineer bei NX drei Jahren und beschäftigt dich somit beruflich mit Monorepos.
Und da habe ich gedacht, dem droppe ich doch mal eine Mail und jetzt sind wir hier und es freut mich sehr, dass wir es geschafft haben.
Vielen lieben Dank für deine Zeit, Max.
Ja, danke euch.
Ich freue mich aufs Gespräch.
Alle Beschwerden aus City Roll bitte an Andi at engineeringkios.dev.
Gibst diese E-Mail-Adresse?
Ihr klappt schon, natürlich.
Ja, dropp die mal.
Vielleicht sollten wir eine Beschwerden at engineeringkeos.dev eigentlich.
Aber steigen wir mal in das ganze Thema ein.
Max, wenn du jetzt mal kurz erklären könntest, wir alle, die mit mir unter dem Stein geschlafen haben oder noch unter einem tieferen Stein geschlafen haben, die letzten zehn Jahre.
Was ist ein Monorepo, worüber sprechen wir da und um was geht es eigentlich?
Wie all die Definitionsfragen eigentlich gar nicht so einfach und jeder wird dann unterschiedliche Meinung haben.
Aber für mich ist ein Monorepo ein einzelnes Repository, wo mehrere Projekte drin sind, die untereinander verschiedene Beziehungen haben, die irgendwie definiert sind.
Also letztlich geht es darum, dass irgendwie Code von verschiedenen Projekten in einem Repository liegt.
Aber wenn man jetzt irgendwie einfach nur einen großen Monolithen hat und einen großen Block an Code, wo alles irgendwie drin liegt und nicht klar strukturiert ist, dann ist es kein Monorepo, sondern man muss schon auch die Beziehungen unter den einzelnen Projekten da nachvollziehen können.
Was man damit macht, ist natürlich die nächste Frage.
Du hast schon gesagt am Anfang, alle haben irgendwie den Hype mitbekommen wegen Google und Monorepos und letztlich all die großen Big Tech-Firmen nutzen, nutzen Monorepos.
Also da muss ja schon irgendwas dran sein.
Auch wenn du und ich und die meisten Zuhörer, Zuhörerinnen vermutlich nicht bei Google arbeiten, können sie trotzdem was von dem von den Benefits mitnehmen.
Letztlich gibt es alle möglichen Orte in der Softwareentwicklung, finde ich, die die Reibung in den Prozess bringen.
Wenn man irgendwie Code teilen möchte mit anderen Leuten, alle möglichen Releases, die man machen muss, um geteilten Code irgendwie miteinander abzustimmen und dann hast du ein Backend-Repo und ein Frontend-Repo und die hängen voneinander ab, aber dann musst du mit den Leuten koordinieren.
Das sind alles so Sachen, die die Verreibung sorgen, die in Monorepo, wo alles in einem großen Ordner ist und du auf alles Zugriff hast und du alles auf einmal ändern kannst und mit einem Commit sozusagen den kompletten Stack verändern kannst und dein neues Feature bauen oder sowas einfach verschwinden.
Hast du gerade geglaubt, irgendwas ist kaputt?
Ja.
Siehst du, so geht es mir auch oft.
Und dann brauche ich unbedingt einen Kaffee.
Oder wie der Andi sagen würde, einen Kaffee.
Und für diese Koffeinenergie, die ihr uns durch diese Kaffeespenden bereitstellt und die es uns eigentlich erst ermöglichen, diese Episoden zu produzieren, möchten wir uns einmal bedanken.
Und zwar bei den letzten Spendern.
Daniel, Jakob, Peter, Alfred, Florian, Michel, Dimo, David, Lukas, Adrian, Nico, Matthias, Wolfgang, by the way, schöner Name.
Elias, Björn, Franco, Dominik, Paul und Fabian.
Und egal, ob ihr uns einen Café sponsert oder vielleicht sogar ein Café-Abo wieder Fabian oder einen ganzen Monatsbedarf an Café wieder David, wir schätzen jeden einzelnen Café und freuen uns wirklich über dieses ganze Koffein-Feedback.
Vielen Dank von Andi und von mir und jetzt geht es auch schon wieder zurück zur Episode.
Du hattest gerade gesagt, ein Monorepo ist nicht einfach ein Repository und wir knallen den ganzen Code da rein, sondern die Beziehungen müssen ersichtlich sein.
Was heißt Beziehungen in dem Kontext?
Habe ich überall README-Files, die dann irgendwie auf andere Folder pointen?
Da gibt es ganz viele verschiedene Lösungen.
Also das kommt dann auch auf das Monorepo-Tool an, die du hast.
Also die, ich würde mal sagen, in der Skala von PNPM, NPM Workspaces, die auch Monorepo-Support haben, was irgendwie so das ganz simpelste Tooling, das sozusagen am wenigsten macht zu Basil auf der anderen Seite, was von eben dem Google-internen Tool abgeleitet ist und immer den Ruf halt als das komplizierteste, was man überhaupt so ins Haus holen kann.
Über dieses ganze Spektrum, haben alle irgendeine Art und Weise Beziehungen zwischen den Projekten zu definieren, sehen immer anders aus.
Bei NPM ist es dann so zum Beispiel oder bei PNPM sind so im Package.json, so Workspaces, Entries, die einfach sagen, okay, hier die und die Ordner sind einzelne Projekte und dann importierst du halt von denen, wie du auch sonst in JavaScript importierst.
So werden dann die Beziehungen zwischen den einzelnen Projekten definiert.
Und auf dem anderen Ende gibt es natürlich auch Sachen, wo du alles Mögliche selber definieren kannst, irgendwelche komplizierten Graphen hast und so weiter.
Wenn wir jetzt von Monorepo sprechen, frage ich mich, ist Monorepo gleich Monorepo?
Oder gibt es Subkategorien und Subarten von Monorepos?
Es ist auf jeden Fall nicht Monorepo gleich Monorepo.
Jeder hat seine eigenen Flavor.
Also zum einen ist ja schon mal die Frage, was ist da drin?
Sind da irgendwie dein paar Frontend-Applikationen und Packages, die dazugehören drin, hast du ein Monorepo mit vielen verschiedenen Sprachen.
Vielleicht nochmal einen Schritt zurückzugehen, in meiner Definition habe ich ja auch nicht gesagt, dass Monorepo heißt, all dein Code in der ganzen Firma muss in diesem einen Monorepo sein.
Das ist, glaube ich, auch viel, was bei der Hype und dann der dazugehörigen Hater-Welle natürlich so ein bisschen mitschwingt, ist dieses gigantische Aufwand, das regel kein Sinn.
So, Google hat all den Code in einem großen Repo.
Und das hat super viele Vorteile für die.
Aber die haben halt auch zehntausende Entwickler, die da drin sind.
Ich habe jetzt keine Zahlen, aber massiv viele Entwickler, die darin arbeiten und deswegen auch massiv große Teams, die sich darum kümmern, dass es alles rundläuft und dass das Tooling alles da ist und sowas.
Aber ganz viele andere Leute, die sagen, wir haben Monorepos, sind da nicht so, inklusive mir, sind da nicht so streng in dieser Definition, dass all der Code muss drin sein, sondern es muss einfach nur mehrere Projekte in einem Repo sein.
Und das ist zum Beispiel schon mal eine ganz, eine ganz große Unterscheidung, dass das Monorepo wie Google und Facebook es zum Beispiel haben, ist nicht das Monorepo des XY-Dutscher Mittelständler hat, obwohl sie ähnliches Tooling verwenden und ähnliche Konzepte dahinter sind und die ähnlichen Vorteile davon haben, halt auf einer anderen Skala.
Okay, da habe ich jetzt gleich noch eine Follow-up-Frage, aber davor möchte ich nochmal auf einen Punkt eingehen, du sagtest gerade Hype und dann die Flip Side, die Hater-Welle.
Und den Hype hat ja der Wolfgang auch im Intro schon angesprochen.
Wolfgang, wenn du dich zurückerinnerst an die Zeit 1960, als du diesen Hype erlebt hast, welche Gründe haben denn, welche positiven Gründe haben denn damals für diesen Hype gesprochen?
Weil die nächste Frage wäre dann an den Max, was denn die Hater-Seite an Hauptargumenta aufgeführt hat?
Ja, die positive Seite war eigentlich primär, was ja Max jetzt schon erwähnt hat, dass die Zusammenarbeit zwischen verschiedenen Teams, Backend und Frontend war ja immer so der Klassiker, dass die eigentlich vereinfacht wird, weil du hast halt immer eine Änderung im Frontend, wenn du auch im Backend eine Änderung hast oder halt oft, vor allem wenn du irgendwelche Schnittstellen änderst, und dass solche Dinge natürlich einfacher sind, wenn du alles ändern kannst oder irgendwelche Libraries sogar noch drin hast, die irgendwie inkludiert werden, dass das alles dementsprechend einfacher wird.
Und das war ja auch das große Versprechen eigentlich, was Monorepos damals mitgebracht haben und worum es dann jeder haben wollte, weil es kennt ja jeder, die Kommunikation zwischen Teams ist schwierig und gerade solche, wann wird was released und was wird zuerst released und die ganzen Probleme, die damit einhergehen und die Pull-Requests, die voneinander abhängen.
Und dann hast du einen Pull-Request, den du zuerst merchen musst, bevor du einen anderen merchen musst, damit die Pipeline nicht zu früh angetriggert wird und und und.
Also das waren ja so die klassischen Probleme, die eigentlich Monorepos damals lösen wollten oder versprochen haben zu lösen.
Und womit kam jetzt die Hater-Fraktion um die Ecke, Max?
Letztlich ist das Schöne, ja, wenn man, was ich jetzt Poly-Repo nenne, sozusagen den gegensätzlichen Approach, wo jedes Projekt ein Einzel-Repository hat, dass man ziemlich einfach out of the box Autonomie hat.
Jedes Team betreut ihr eigenes Repo.
Sie haben komplette Flexibilität darüber, wie sie gestalten, welche Technologien da drin sind, welche Tools sie verwenden für das Testen, fürs Bilden und so weiter, wie sie releasen, deployen.
Alles drumherum sozusagen, es ist autonom.
Und wenn da jetzt jemand kommt und sagt, hey, da gibt es noch diese anderen hundert Leute, die alle euch nicht so gut leiden könnt, weil dort immer an unterschiedlichen Enden vom Tisch bei irgendwelchen Company-Diskussionen.
Jetzt bitte macht doch mal alles mit denen zusammen in einem Repo, das natürlich erstmal Widerstand, weil der Gedanke dann ist, dass man da Autonomie und Flexibilität und eben Geschwindigkeit irgendwie aufgibt, was nicht sein muss.
Aber es ergibt Sinn, dass der Gedanke erstmal da ist und es braucht eben auch Arbeit und Design, um zu schauen, dass man die Vorteile erhält.
Also du kannst in einem Monorepo immer noch komplett autonom deine Technologie bestimmen und bestimmen, wer kontributen kann zu dir, dass nicht irgendwelche Leute kommen und einfach random Code bei dir ändern und dann sitzt du plötzlich auf den Folgen.
Das kann man immer noch alles so einrichten, aber es braucht eben ein bisschen mehr Aufwand als dieses schön isolierte Out of the Box.
Ich habe mein eigenes Repo, ich kann machen, was ich will, Modell.
Du hattest gerade was Schönes gesagt, beziehungsweise einen großen Mythos aufgelegt oder aufgelöst, aufgelegt, ein Mythos aufgelegt, ist auch gut, aufgelöst.
Und zwar hast du gesagt, Monorepo heißt nicht, dass die ganze Firma alles in ein Repo klatschen muss, sondern dass man auch mehrere Monorepos haben kann.
Oder man kann auch ein Monorepo haben und etliche Polirepos.
Polirepos, wenn ich das richtig verstanden habe, ist wirklich eine Applikation oder ein Package in einem Repository.
Das, was wir klassischerweise von GitHub so kennen, oder?
Ja, genau.
Da frage ich mich, okay, wie sehen denn klassische Monorepo-Unterteilungen aus?
Habe ich jetzt in einer Firma, wo ziemlich viel Go und Java geschrieben wird und JavaScript, habe ich dann ein Monorepo für Go und eins für Java und eins für JavaScript?
Oder ist das eher so, dass ich eine große Applikation habe und diese große Applikation hat ein Frontend, ein Backend, dann Terraform für die Infrastruktur und dann noch eine Mobile-App.
Und all diese Sachen sind dann in einem Monorepo, weil die zu einer Applikation hat.
Also was sind so klassische Aufteilungen, die du in der freien, kann ich jetzt Wirtschaft, Welt oder Natur sagen?
Weiß ich nicht.
In der freien Natur so ist es.
Philosophische Frage, würde ich sagen.
Wo sind die Grenzen in der freien Wildbank, wolltest du sagen an?
Ja, das ist die Frage.
Wenn ich durch den Wald stapfe und mir die Monorepos anschaue, die ich sehe, dann.
Also, was ganz klassisch ist, würde ich sagen, ist so dieser Front-end, Backend-Split, also nach Technologie aufgesammelt.
Sozusagen viele Monorepo-Tools, die auf dem weniger komplexen Spektrum, das ich vorhin schon aufgemacht habe, sind, die sind irgendwie für eine Sprache gedacht.
Also zum Beispiel Turbo Repo oder PNP-Workspaces und sowas, das sind alles Monorepo-Tools, die sich um JavaScript kümmern.
Und deswegen, was viele Leute machen, ist, all ihren Frontend-Code in Monorepo tun.
Da hast du dann vielleicht mehrere Applikationen, Design System, irgendwelche Shared Libraries und so weiter und so fort.
Und der Backend-Code ist dann in einem anderen Java-Repo oder sowas.
Das ist so ein ziemlich, ziemlich klassischer Split, den ich viel sehe, nach Technologie sozusagen.
Und also was wir zum Beispiel machen, ich meine, wir bauen Monorepo-Tooling und wir haben nicht ein großes Monorepo.
Also NX an sich ist ja erstmal komplett Open Source und MIT-Licensed und kostenlos.
Also da muss man nicht für zahlen, das ist in einem Repo, das auf GitHub existiert.
Da ist ganz viel drin.
Das ist ein großes Monorepo, da sind verschiedene, wir haben so eine Graph-Applikation zum Beispiel, die noch mit da drin ist, neben dem ganzen CLI-Tooling an sich und den einzelnen Packages für die einzelnen Technologien, die wir supporten und so weiter und so fort.
Aber unser Closed Source, Cloud-Applikationen, all solche Sachen, die sind halt trotzdem in einem anderen Monorepo, weil das ja auch dann logistisch nicht funktioniert, wenn du es einer MIT-Licens und Open Source ist, dass dann kannst du nicht dann noch deinen eigenen privaten Code drin haben.
Und sonst ist das, was du, was du erwähnt hast, schon auch sehr sinnvoll, dass man irgendwie das nach Domain, würde ich mal sagen, gruppiert im gröberen.
Das ist auch ganz wichtig in diesem Entscheidungsfindungsprozess Monorepo pro Contra, ist, wo ziehen wir die Linie, dass es noch Sinn ergibt, die Sachen auch in einem Monorepo zu tun.
Also dieses Back-end-Frontend in einem Repo ist auch total sinnvoll.
Es löst total so viele Probleme.
Aber wenn ich jetzt ein komplett unrelatetes Backend-Auto da rein tue, das mit meinem Frontend gar nichts zu tun hat, mit denen mein Team gar nichts zu tun hat, die andere Technologien verwenden, dann fragt man sich irgendwann, okay, mache ich mir hier mehr Probleme, als dass ich welche löse.
Und deswegen dieses Gruppieren nach Domain, dass all die Sachen auch irgendwie zusammenpassen, ist so eine Grundsatzleitlinie, der ich davor irgendwas.
Das heißt, du bist eigentlich ein Verfechter, wenn ich das richtig raushöre, von so einem hybriden Approach.
Man hat nicht ein Repo, wo alles drin liegt, wie es bei Google mehr oder weniger so ist.
Und auch nicht, ich habe nur wirklich ein Modul oder Building-Block von meinem Stack sozusagen in einem Repo, wo ja nichts anderes drin sein darf und alles muss wirklich nur ein Bildskript darf da drin sein und eine Pipeline und ja nichts anderes, sondern irgendwie in Zwischenweg, da wo es Sinn macht, legen wir Sachen zusammen und weichen diese Grenzen ein bisschen auf, um eben einen schönen Mittelweg zu finden.
Jetzt wäre meine Frage noch, warum Mittelweg und nicht dieses, ich backe alles in ein Monorepo, weil es funktioniert ja auch, zumindest bei große.
Total.
Also ich bin da voll ein Verfechter des Pragmatismus, würde ich mal sagen, dass das Zusammenpacken, was gut zusammenpasst.
Warum nicht alles in ein Repo packen?
An sich hat es auch Kosten, Sachen in ein Monorepo zu packen.
Da müssen plötzlich ganz viele Leute miteinander arbeiten, die vielleicht im normalen Arbeitsalltag gar nicht so viel miteinander zu tun haben.
Die müssen ja auch irgendwie auch auf einen gemeinsamen Nenner kommen.
Sowas wie welches Monorepo-Tool verwenden wir zum Beispiel.
Wäre schon mal wichtig, dass sich da alle einig sind, damit man auch alle auf einem Monorepo-Tool irgendwie zusammenbringen kann.
Also Sachen wie CI-Pipelines, wenn da jetzt jeder andere Vorstellungen hat, welches Tool sie verwenden wollen, ist es auch eher eher sicher theoretisch möglich, aber auch eher anstrengend.
Also so ein gewisser Wille, da irgendwie zusammenarbeiten und zu standardisieren und zu konsolidieren zu wollen, muss schon da sein.
Und der Wille ist eben auch psychologisch, würde ich sagen, und in den Köpfen der Menschen und in den Organisationsstrukturen und gar nicht so ein psychologisches Problem.
Also, was ich, was ich sehe bei Kunden von uns, was ich immer wieder höre, ist, dass das Monorepo dann auch so ein Magnetismus an sich entwickelt.
Wenn du mal anfängst, irgendwo kleine Gruppierungen zu machen, wo es Sinn ergibt, dass dann auch immer mehr Leute merken, uh, es hat ja Vorteile in den Monorepo-Zeiten.
Ich will da mit rein und dann der Bein von ihnen kommt und dann ist immer größer wird und immer größer und die Vorteile sich immer weiter verbreiten in der Firma.
Wenn jetzt aber von oben die Devise kommt, so jetzt Monorepo alles zusammen, dann wird man die Reibungen in der Firma und in den ganzen verschiedenen Technologien, die da zusammenspielen, schon merken.
Jetzt kommen wir nochmal mit einer Geschichte aus dem Krieg.
Ich hatte mal den Kontakt mit einem Feature von Git, und zwar nennt sich das, glaube ich, Sub-Modules, wenn mir nicht alles täuscht.
Wir hatten gerade eine Episode über Git übrigens, dass man ständig neue Features lernt.
Und ich hatte damals über das neue Feature Submodul gelernt, wo man Repos einbinden kann in ein geklontes Repo, also dass sie so Sub-Modules, die eigentlich in einem anderen Repo liegen, mir einbinden kann.
Ihr habt das mal versucht, es war absolutes Chaos und es hat nichts funktioniert.
Es war, also ihr habt das, glaube ich, ein oder zweimal versucht und hab's dann aufgegeben und das war auch das, was ich von anderen Leuten gehört habe.
Wir sprechen jetzt wirklich, wir klatschen alles in einen Repo.
Wer so Submodule-artiges Vorgehen, irgendwie eine Alternative.
Kennst du das überhaupt?
Hast du da eine Meinung dazu?
Ich habe davon auf jeden Fall schon gehört und es immer wieder gesehen.
Ich habe sehr bewusst die Finger fahren gelassen, weil ich immer genau die gleiche Geschichte höre.
Es ist komplett das Karte.
Ja, gute Entscheidung, hätt ihr jetzt auch gesagt.
Ich kann jetzt nicht First Hand sozusagen über die Rot-Contra sprechen, weil ich, wie schon gesagt, nicht viel Erfahrung damit habe.
Aber was ich sozusagen immer wieder sehe, ist, dass es gar nicht was ist, was man braucht irgendwie.
Letztlich.
Bei bei all den normalen Repo-Größen, die jetzt vielleicht nicht Google sind, wo es wirklich die GIP dann auch strapaziert wird, jetzt mit den Datenstrukturen und sowas.
Ist es auch einfach okay, die Sachen dann als normale Dateien in einem großen Repo zu haben.
Die Vorteile sind ja auch eigentlich dann nicht mehr so groß, weil du hast ja dann trotzdem in MPool-Request zum Beispiel nicht die übergreifenden Commits sozusagen auf mehrere Repositories, weil es sind ja im wirklichen Leben, lokal bei dir sind sie zwar vielleicht in einem Folder, aber in der Realität sind sie dann natürlich aufgeteilt auf mehrere Repositories und dann hast du ja wieder dieselben Probleme, dass du nicht einen Pull-Request haben kannst, den du einfach einmal durchpusht und dann geht es an fünf verschiedenen Ecken los und die CI, CD-Cripelines rennen los.
Haben wir nicht viel gewonnen.
Ich frage mich gerade, wie kompliziert es eigentlich ist, um zu entscheiden, ob ich auf ein Monorepo oder Poly-Repo gehen möchte?
Denn wir haben gerade schon die Strukturfrage geklärt.
Wie strukturiert man das, Applikation, Sprache und so weiter.
Und mit hoher Wahrscheinlichkeit gibt es dann noch Hybrid-Modelle und ganz viele andere Modelle.
Die zweite Frage ist, besteht überhaupt eine Intention zu einer Art von Chantisierung über Teams hinweg?
Weil Teams wollen ja unabhängig sein und wir wollen ja alle schnell sein und Standards und so weiter funktionieren in 90% der Fälle und in die 10% nicht und so weiter und so fort.
Deswegen frage ich mich, hast du ein mentales Modell, ich sag mal, ein Decision-Tree, ein Entscheidungsbaum, zu sagen, das sind die Fragen, die Entwickler-Teams oder Firmen sich stellen sollten.
Und wenn sie die eine mit Ja und die anderen mit Nein beantworten, dann ist ein Monorepo vielleicht nicht das Richtige für sie.
Denn auch später CI umzubauen, Applikationen über Repos hinwegzuschieben, die haben vielleicht eine direkte Connection zu irgendeinem Kubernetes und zu einem automatischen Deployment und so.
Also ein Repo umziehen ist ja heutzutage bei moderner Infrastruktur gar nicht mal so einfach durch die ganzen Querverbindungen.
Genau.
Habt ihr, habt ihr da irgendwie so ein Entscheidungsbaum oder eine Leitlinie oder zwei, drei Leitfragen, die man sich stellen kann und sagen, okay, hab da macht es Sinn, sich weiter über Monorepos Gedanken zu machen?
Also die wichtigste Frage würde ich sagen, ist, kann ich es aushalten, mit meinen anderen Teams in einem Raum zu sein.
Oder hasse ich die absolut?
Das ist die wichtigste Sache, würde ich sagen, weil wenn ihr euch gar nicht leiden könnt, dann wird es Schmerz sein.
Abgesehen davon, ich, ich meine, vielleicht bin ich auch voreingenommen natürlich, weil ich an einem Monorepo-Tool arbeite, aber letztlich, ich finde, Monorepo ergibt immer Sinn.
Von ganz klein bis ganz groß.
Weil der Overhead gar nicht mehr so groß ist.
Die Sache ist, wenn du, wenn du anfängst, ein Projekt zu bauen und du machst irgendwas, was nicht nur ein kleines Mini-Spielzeug oder Vibe-Codetes Ding ist oder sowas, dann wirst du früher später immer an diesen Punkt kommen, wo du plötzlich Code teilen muss zwischen zwei Sachen oder jetzt muss ich auch noch Tests für das neue Projekt schreiben.
Und jetzt muss ich mich wieder um das Tooling kümmern, dass ich mich da schon 15 Mal gekümmert habe in letzter Zeit.
Und das sind alles Sachen, wo Monorepos massiv helfen.
Die Kosten auf der anderen Seite, wie ich ja vorhin schon gemeint habe, sind eher so das Umziehen und das Koordinieren und sowas mit den Leuten.
Und halt irgendwie Verantwortung auch dafür zu schaffen, dass jemand sich um das Tooling kümmert.
Das ist also, wenn ich über das Neuem anfange, einfach Monorepo und Happy sein und dann werden dann Sachen für Stück für Stück damit reinkommen.
Wenn ich die Entscheidung treffe, will ich umziehen, will ich jetzt anfangen, alles zu migrieren, dann ist es natürlich viel eher eine Abwägung, so welche konkreten Painpoints habe ich, so warum will ich das, also warum mache ich mir diesen Gedanken überhaupt.
Und dann ist es natürlich super persönlich und super Team- und Film-spezifisch.
Deswegen, sorry, wenn es ein bisschen unbefriedigend Antwort auf die Frage ist, ich kann ja da keine so klaren Leitfaden geben.
Aber mein Leitfaden wäre Monorepo bei Default.
Und wenn schon diese existierende super komplexe Infrastruktur da ist, dann sich genau überlegen, was man sich erwartet von dem Effekt.
Ja, das ist kein Problem, nachher, wenn wir die Episode fertig haben, dann lasse ich die einmal irgendwie transkripieren und dann durch Claude sagen und sagen, baut mir mal ein Decision-Tree daraus.
Und dann schicke ich dir denen, dann könnt ihr denen auf eurem Marktding rausstellen.
Das ist gar kein Problem.
Danke dir.
Jetzt werden wir mal kurz in Richtung Tooling schauen, weil das war ja immer die Argumentation, warum Monorepos nicht funktionieren.
Und da fällt mir jetzt so spontan ein, keine Ahnung, ich habe Frontend und Backend in meinem Repo drinnen.
Und ich schaffe es aber nicht, zum Beispiel in meinem Default-Deployment von Frontend, was irgendeine JavaScript-Web-App ist, einfach zu unterscheiden, wann soll die bauen, die sollen nur bauen, wenn zum Beispiel im Frontend sich was geändert hat und nicht im Backend so die üblichen Sachen.
Ich will ja nicht alles loustriggern, wenn sich nur irgendwo ein Typo geändert hat.
Solche Dinge, also ganz grundlegende Sachen zum Beispiel.
Für mein Deployment kann Cloudflare überhaupt das sinnvoll unterscheiden.
Bau nur, wenn sich im Folder Frontend was geändert hat, zum Beispiel.
Also ich weiß zufällig, das funktioniert mittlerweile, aber vor ein paar Jahren war es wahrscheinlich schwieriger.
Jetzt würdest du sagen, man kann einfach darauf losstarten, das, auch wenn man jetzt kein spezielles Tooling hat, ist nicht so schlimm.
Heutzutage ist es eh kein Problem im Notfall-Triggern, halt 5 CD-Pipelines und nicht so schlimm.
Oder muss man sich im Vorhinein schon überlegen, okay, was für ein Tooling brauche ich, wie geht es alles an und braucht es da ein Prozess, wo man sich wirklich überlegt, was man macht, oder kann man einfach mal losstarten, deiner Meinung nach?
Also einfach nur losstarten und experimentieren, kann man auf jeden Fall.
Da muss ich sagen, lieber anfangen und probieren, als sich zu viel Gedanken machen über alles.
Und dann wird man schon merken, wo es irgendwie noch hakt.
Letztlich ist aber die Tooling-Geschichte natürlich super wichtig, weil je größer dein Repo wird, wie du schon gesagt hast, so ich kann nicht, wenn ich Google bin, sagen, ah ja, irgendwer hat eine Änderung gemacht, ich lasse jetzt nochmal alles durchlaufen.
Und dann wird Google Maps gebaut, obwohl ich ganz woanders irgendwas geändert habe.
Weil dann würde deine CI-Pipeline ja auch irgendwie vier Tage brauchen, bis sie durchgelaufen ist oder sowas.
Und da wird es dann nach dem rumprobieren und Spaßprojekt auf jeden Fall wichtig, dass du Tooling hast in CI auf jeden Fall.
So Sachen wie, was du schon erwähnt hast, so eine Art von, also bei uns heißt es Affected, dass du sozusagen anhand der Änderungen in deinem Pull-Request sagen kannst, okay, diese Sachen müssen neu gebaut werden, neu getestet werden und so weiter und so fort.
Aber dann sind es auch Sachen wie Caching zum Beispiel.
In so ein Monorepo haben ja Dutzende, Hunderte, wie viel auch immer, Developer dann die ganze Zeit Tasks laufen und deine CI-Maschinen laufen durch und durch und durch und machen Sachen.
Da zahlt man dann irgendwann schon viel für Compute, wenn wir das einfach alles immer wieder machen.
Und da kann man viel rausholen, indem man das nicht, dass nicht jede Berechnung zweimal gemacht werden muss.
Ich weiß nicht, ob ihr schon mal so versucht habt, irgendwie so komplexeren Bild aufzubauen mit so MPM-Skripts oder sowas, wo man hat, okay, ich baue mein Script und dann muss ich Build und Setup Publish und Copy hier und dahin.
Und dann plötzlich hat man dieses ewig lange Ding, das ist natürlich auch nicht maintainable at scale.
Das sind also Sachen, wo Monorepo-Tools wie in X zum Beispiel oder ganz viele andere natürlich auch so helfen.
Also zum Beispiel, was ganz klassisch ist, was eigentlich alle machen, ist so ein Project Graph aufbauen in irgendeiner Form und Weise, dass du siehst, das sind all die verschiedene Projekte in meinem Repo, so hängen sie voneinander ab.
Und wenn ich dann sage, ich möchte dieses eine Projekt bauen, dann kann mein Monorepo-Tool anhand von Konfigurationen und anhand von eben Statische Analyse von Imports und sowas genau sagen.
Ich möchte Projekt A bauen, dann muss ich ja auch noch Projekt B und Projekt C bauen und das und das noch kompilieren und das davor hin und her kopieren und solche Sachen, dass man die Beziehung zwischen den Tasks auch einfach deklarieren kann, statt zu sagen, ich muss jedes Mal genau definieren, was all die Schritte sind, die passieren müssen.
Wie baue ich diesen Graph auf?
Ist das jetzt was Manuelles?
Brauche ich da wieder ein spezielles Tooling dazu oder sprichst du jetzt eher vom Konzeptionellen?
Also, wie funktioniert das dann in der Praxis?
Das kommt ganz aufs Tool an.
Also auf dem ganz einen Ende des Spektrums, so PNPM, NPM Workspaces, die analysieren einfach JavaScript-Imports.
Punkt.
Wird zwischen den verschiedenen Ordnern dann diese Beziehungen definiert durch die Imports und das war's.
Bei ein X zum Beispiel, also zum Beispiel zwischen einem Front-end und Backend wirst du ja kein Import in deiner Datei irgendwo haben, sondern da ist dann vielleicht irgendwie eine URL, die irgendwie gehittet wird für die API.
Da muss man dann natürlich manuell nachhelfen und sagen, okay, mein Frontend hängt irgendwie von meinem Backend ab, muss diese Beziehung irgendwie definieren können.
Also was an X ist natürlich nicht zu sehr, ich mich selber pushen, aber was auch cool daran ist, ist, dass wir Plugins für alle möglichen verschiedenen Technologien, alle möglichen verschiedenen Ökosysteme haben, dass dieses Imports analysieren und Beziehungen zwischen den verschiedenen Projekten auch für Java und Kotlin funktioniert und auch für Go und PHP und alle solche Sachen, dass man möglichst wenig an diesem Project Graph selber rumdoktern muss.
Weil das ist ja auch was, was, wenn du Google bist, dann kann jetzt keiner da hinkommen und sagen, okay, ich definiere jetzt wie jedes System von jedem anderen System in diesem Monorepo abhängt, woran Leute seit Dutzenden von Jahren irgendwie schrauben und da muss ein automatischer Schritt dabei sein.
Das muss irgendwie mehr oder weniger durch statische Analyse passieren.
Du hast mir jetzt schon eine Antwort gegeben auf meine nächste Frage, die ich eigentlich stellen wollte, weil auch wenn du jetzt selber NX nicht hervorheben willst, tue ich das jetzt mal kurz, beziehungsweise ich habe so das Gefühl, dass in den letzten Jahren schon gewisse Grundfeatures so in den ganzen Toolchains dazugekommen sind.
Jetzt in GitHub-Actions kann ich definieren, eben nur wenn sich was in einem gewissen Folder geändert hat, dann trigger eine Action.
Cloudflare habe ich erwähnt, die können auch prüfen, automatisch hat sich nur was in dem Folder geändert, dann trigger mir das Deployment von meinem Frontend zum Beispiel.
Bei Netlify, keine Ahnung, weiß ich schon wieder nicht, ob das funktioniert, aber man sieht schon so eine gewisse Bewegung in diese Richtung, dass es solche Features gibt, wobei das nie Monorepo-Feature heißt.
Also das ist halt ein kleines Feature, aber man merkt schon, dass man dadurch Monorepos überhaupt ermöglicht, weil vor zehn Jahren war das einfach unmöglich, beziehungsweise halt man hat sehr viel customizen müssen, um überhaupt in die Richtung zu gehen.
Jetzt hast du die Graphen schon genannt, also die Abhängigkeiten.
Was wären denn sonst noch so Key Features oder so grundlegende Features, die man eigentlich braucht in den Monorepo, die jetzt NX zur Verfügung stellt, die ja zum Beispiel GitHub-Actions noch nicht automatisch kann oder vielleicht zu komplex sind.
Genau, also ich würde da unterscheiden zwischen CI-Features, weil es ja einfach ein ganz wichtiges Thema ist für Monorepos und lokalen Features.
Also lokal die wichtigen Sachen sind eben dieser Project Graph und der sich daraus ableitende Taskgraph sozusagen, wo ich irgendwie definieren kann, so Pipelines, wie läuft mein Bild, das dann auch maintainable ist.
Das finde ich immer ein bisschen schwer, den Leuten irgendwie zu vermitteln, dass so Monorepo-Tooling auch so ganz oft so Death by a thousand Cuts ist irgendwie.
Es gibt einfach so ganz viele kleine Probleme, die aufkommen werden.
Und Tooling wie ein X hilft an ganz, ganz, ganz vielen verschiedenen Orten verschiedene Sachen zu machen.
Ganz, ganz grob neben dem ganz Core-Teil des Project Graph und Task Orchestration und Caching, solche Sachen, gibt es eben auch alle möglichen Features wie automatierte Migrationen zum Beispiel.
Dass wenn alle in einem großen Repo sind und dann muss eine Version geupgradet werden, dann ist es jetzt ganz schön schwer, wenn ihr sagt, okay, wir machen jetzt ein Pull-Request und erst machst du deine Änderung, dann machst du deine Änderung, dann machst du dir.
Oh, jetzt gibt es Merch-Conflex, müssen wir von vorne anfangen.
Da braucht man automatierte Migrierungen, Migrationen, um diesen Prozess sozusagen zu helfen, zu helfen.
Guidelines, Standards.
Was NX eben auch hat, sind Generators, also Code-Generierung, was eben ganz wichtig ist, um Code Quality und Standards in der Firma zu erhalten.
Weil natürlich jeder seine eigene Meinung hat dazu, wie irgendwas passieren sollte, wenn plötzlich jede Komponente, jedes neue Projekt irgendwie anders aufgebaut sind, dann wird es ganz schnell, wird es ganz schnell chaotisch.
Neben den Core-Features sind lokal noch ganz wichtig, jegliche Features, um deine Firmenpräferenten zu encoden irgendwie und Guidelines zu encoden.
Wir haben dann auch Sachen wie Regeln, die man definieren kann, wie verschiedene Projekte voneinander abhängen können.
Wenn ich jetzt eine Library habe, die sich nur darum kümmert, irgendwie mit der API zu reden und das in irgendeinem speziellen Format auszuführen, dann darf die auf jeden Fall nicht the React-Komponente importieren.
Weil dann ist irgendwas ganz ordentlich schiefgegangen.
Und sowas ist eben super wichtig, dass auch wenn deine Firma immer weiter wächst, die Struktur von deinem Code noch übersichtlich bleibt.
Und dadurch ist es eben nicht so, dass dein Projekt immer weiter wächst und alles wird chaotisch und gar kein Überblick mehr.
Und dann, ah, okay, jetzt sind drei Jahre vergangen, jetzt fangen wir nochmal von vorne an und bauen das Ganze auf neu auf, weil das alte kann man gar nicht mehr anschauen.
Sondern das Projekt wächst und entwickelt sich aber in eine Richtung, die auch nachhaltig ist.
So jetzt lange geredet für die eine Seite, die das lokale Tooling.
Auf der anderen Seite ist das CI-Tooling super wichtig, weil wie schon gesagt, irgendwann brauchen deine Pipelines vier Tage und dann kannst du keinen Bug mehr fixen.
Und dann stehst du ganz schön blöd da.
Also, was super wichtig ist, ist eben Caching, dass du nicht immer alles nochmal neu ausführen musst, sondern wenn jemand irgendeinen Task schon wo ausgeführt hat mit den gleichen Inputs, also dem gleichen Bild auf den gleichen Dateien, mit den gleichen Environment Variables ausgeführt hat, dann kann ich den einfach mir direkt aus dem Cache ziehen und muss das nicht nochmal ausführen.
Dieses Affected, was du schon erwähnt hast, dass man nicht immer alle Builds laufen lassen muss und nur die, die wirklich relevant sind für meine Veränderungen.
Also die beiden zusammen helfen schon massiv dabei, so in einem großen Mono-Repo die CI-Zeiten runterzuhalten, weil dadurch skaliert die Zeit, die deine CI braucht, nicht mehr mit der Größe des Repos, sondern mit der Größe der Änderung, die du machst.
Wenn ich jetzt irgendein kleinen Typo irgendwo fixe, dann müssen nur ganz wenige Sachen neu gebildet und getestet werden und fertig.
Und wenn ich einen massiven Refactor mache, der alle möglichen Bereiche des Repos affected, dann muss ich eben mehr bauen und mehr neu testen und dann wird es alles länger brauchen.
Das Problem damit ist, dass das immer irgendwann kaputt gehen wird.
Es gibt immer den einen Pull-Request, der irgendwas ganz Zentrales ändert, was alles in dem ganzen Repo affected und dann plötzlich stehe ich wieder vor diesen vier Tagen CI-Pipeline Execution Time und das ist einfach nicht machbar.
Und deswegen, was man at einer Skala immer irgendwann braucht, ist Distribution in irgendeiner Art und Weise.
Also die Möglichkeit, deine Tests nicht alle in einer langen GitHub Actions-Pipeline auszuführen, sondern über mehrere Runner, über mehrere Jobs, Agents, wie auch immer die Abstraktion in eurem CI-Tool of Choice heißt, zu verteilen.
Scheint erstmal nicht so kompliziert, zu sagen, wir packen halt jetzt drei GitHub Actions-Runners ein und da werden die Sachen ausgeführt.
Aber dass das auch mehr oder weniger effizient ist, ist gar nicht so einfach zu gestalten, weil all diese Sachen haben ja auch Abhängigkeiten voneinander.
Wenn dann einer Runner plötzlich alle Builds ausführen soll und der andere alle Tests, dann kann es sein, dass der eine fünf Stunden braucht und der andere nach einer halben Stunde fertig ist und dann drumherum steht, das ist nicht sehr effizient.
Ich rede einfach mal ein Beispiel, das ist ein bisschen einfacher zu verstehen, glaube ich.
Wenn ich ein Bild auf dem einen ausführe, dann braucht der Bild ja fünf andere Sachen, die da vorgelaufen sind.
Dann muss ich jetzt irgendwie schauen, dass all diese Builds nur auf dem einen Runner laufen, weil sonst muss ich sie ja gleichzeitig auf mehreren Runnern laufen lassen.
Und dann merkt man, wenn man sich dann all die Szenarien mal anfängt runterzurechnen, merkt man, dass es plötzlich ganz schön kompliziert wird, so eine Distributed Pipeline zu schaffen, die effizient ist, keine Zeit verschwendet, aber auch keine Sachen zweimal ausführt.
Und das ist dann genau der Ort, wo NX und andere Monorepo-Tools ansetzen.
Ich meine, dieser Dependency-Graph, von dem Wolfgang gesprochen hat, ich meine, jedes Bildsystem.
Sei es NPM, Go, Rust, jeder Compiler baut sich dieses Bildsystem ja auch auf.
Diese Build-Dependencies, meine ich, Entschuldigung, diesen Graphen.
Und ich kenne jetzt nur, ich kenne jetzt NX nicht, ich kenne nur Basel.
Basil, wenn man das mal googelt, dann googelt man am besten nach Blaze.
Blaze ist das interne von Google.
BASIL ist dann die Open Source-Version davon, ähnlich wie Borg und Kubernetes bei Google.
Und da gibt es auch so ein Dependency-Graph und dann gibt es auch so eine Konfigurationsdatei, die wird mit der Sprache Star lag geschrieben.
Ein bisschen wild, aber da wird halt auch gesagt, okay, die Dependencies sind A, B und C und dann baut ihr den Dependency-Graphen.
Und was das Tolle ist, wenn du diesen Graphen explizit hast und nicht neu errechnen musst, dann kannst du natürlich Remote-Caching auch enorm nutzen.
Das, was du auch gerade gesagt hast.
Man kann halt sagen, okay, in Dependency B hat sich jetzt gar nichts geändert, deswegen habe ich das schon pre-compiled und es hat sich seit sieben Wochen nicht geändert.
Deswegen liegt im Remote-Cache diese Pre-Compiled-Dependency bereits drin.
Und jetzt das Tolle, wenn ihr lokal zum Beispiel wieder was mit BASIL baut, dann kann sich jeder Entwickler diese Cached-Pre-Compiled Dependency bereits runterziehen.
Und dann kriegt man natürlich auch Build-Times, von denen du gerade auch gesprochen hast, die dann sehr lange sind, natürlich auf Sekunden runter, weil du Dependencies vorkompilieren kannst und Remote-Cachen.
Und das fand ich unglaublich stark bei Basil zumindest.
Aber ich sage auch ganz oben drauf, mit Starlack und einem ordentlichen Remote-Cache zu handhaben und zu operaten und allem drum und dran.
Ich habe das Gefühl, du brauchst das schon so ein eigenes Dev-Tool-Team, um das wirklich ans Fliegen zu kriegen und auch wirklich gute, ich nenne es mal Monorepo-Infrastruktur hinzubauen, obwohl ich inzwischen auch sage, und das wäre die Frage: Wo ist eigentlich der Unterschied zu diesen ganzen Herausforderungen, die ein Monorepo hat, gegenüber einem Repository, wo einfach nur sehr viel los ist.
Weil das kann ja auch eine große Library sein, wo 20 Entwickler, inzwischen 20 Tenx-Entwickler, hämmern darauf rum, ja, und alle 20 haben Merch-Rechte, die Unterschiede oder die Herausforderungen im CI-System sind doch dann eigentlich dieselben, oder?
Merge-Konflikte, Merge-Ques, Remote Caching, Compute-Power und so weiter und so fort.
Die sind doch eigentlich genau die gleichen wie bei einem großen Monorepo, oder?
Letztlich ist ein Monorepo ja auch nur ein großes Repo, wo viel los ist drin.
Nur es ist eben der Versuch, da das auch zu strukturieren auf eine Art und Weise, dass es nicht so viel zu Problemen führt.
Also wenn man einfach nur zehn gigantische Dateien hat mit tausenden Lines of Code, dann wirst du viele Merch-Konflikte haben.
Wenn du im Gegensatz dazu das Ganze irgendwie klar strukturiert hast in Libraries, die voneinander abhängen, wie ich das vorhin genannt habe, dann hat man viel, viel weniger Probleme damit.
Aber so die grundlegenden Sachen an die Zeit, die Compute braucht und sowas, klar, am Ende ist es das Gleiche.
Du hattest initial gesagt, einer der Herausforderungen bei einem großen Monorepo sind auch die Compute-Kosten.
Weil du hast ja ziemlich viele CI-Builds laufen.
Und wenn ich dann jetzt weiterdenke in Bezug auf ein Poly-Repo, wo sehr viel los ist, wo 2010x-Entwickler drauf sind, ich mag dieses Bild.
Ich hätte gerne mal ein Team von 2010-Entwickler.
Was ist eigentlich ein 10x-Entwickler?
Lass uns mal philosophisch werden.
Dann kenne ich unter anderem auch die Technik, dass man sagt, du bundelst einfach fünf Pull-Requests.
Also du führst nicht jeden Pull-Request einzeln aus, sondern du bundelst einfach fünf Pull-Requests, mercht die alle zusammen und führst dann die CI einmal für das Repo mit den fünf Pull-Requests Applied aus und sagst, wenn es grün ist, alles super.
Das heißt natürlich nicht, dass der Bild nicht failt, wenn die einzelnen Sachen gemercht werden.
Und nur wenn der CI failt, dann machst du eine Art Binary-Split.
Dann machst du eine Art Binary-Split und sagst, okay, welcher Merge-Request, welcher Commit war denn jetzt hier der Failure, weil dadurch nimmst du nämlich die Annahme, dass die Tests grundlegend durchlaufen, nur im Fehlerfall musst du dann weitere CI-Execution haben.
Ist sowas bei Monorepos eigentlich auch.
Ja, ja, so Merge-Ques als Konzept letztlich.
Total, total verbreitet.
Also viele von unseren Kunden, die NX verwenden und eben Enterprise-Contracts haben, wo wir auch dann viel irgendwie mit denen reden und interagieren und Repo optimieren und sowas, die verwenden sowas auch.
Das ist eher ein Problem später.
Also wenn du wirklich viele Entwickler hast, die da auf einmal arbeiten.
Und es hängt natürlich auch davon ab, wie gut, wie dann dein Repo strukturiert ist und wie du deine Arbeit strukturierst.
Also, weil sozusagen viel kannst du ja auch vermeiden, indem du irgendwie dafür sorgst, dass nicht alle die ganze Zeit in den gleichen Dateien arbeiten.
Um nochmal zurück auf deine Frage zu gehen, der Compute-Kost an sich ist gar nicht so das, oder zumindest das Problem, das ich mitbekomme oder über das Leute reden, weil du ja viel optimierst.
Also der unoptimierte Compute-Cost wäre ein Problem, wo du einfach alles die ganze Zeit ausführst und das ist kein Problem.
Aber der optimierte Compute-Cost, wo man nur Effekted macht, wo man Caching hat und so weiter und so fort, ist jetzt nicht was, wo wir zumindest oft hören, oh nein, das ist uns so teuer, wir brauchen da eine Art und Weise, unsere Pull-Requests zu bundeln.
Das Problem, was Merge-Cues eher lösen, ist halt Merge-Konflikte und sowas.
Also wenn, dass man nicht die ganze Zeit immer rebasen muss und jetzt ist das eine reingegangen, jetzt kann ich mein Pull-Request muss ich von vorne anfangen.
Und wenn halt jede Minute ein Pull-Request reingeht in deine Repo, weil du so viele Leute hast, die da dran arbeiten, dann wirst du da halt die ganze Zeit Konflikte haben.
Das ist eher das Problem, was Merge-Ques meiner Erfahrung nach lösen.
Wir hatten gerade nochmal zu der Historie gesprochen, beziehungsweise der Wolfgang hat vom Krieg erzählt.
Wolfgang, du hattest gerade gesagt, das war vor 10 Jahren, zwölf Jahren.
Von welchem Jahr haben wir da gesprochen?
Der Hype, meinst du?
Deine Sichtweise auf den Hype, ja.
Hat man ja schon geklärt.
Der Start des Hypes, ja, jetzt so gesagt, irgendwann 2015 hat das Ganze so begonnen.
Wäre jetzt meine Einschätzung, aber ohne es überprüft zu haben.
Eine Argumentation, die, an die ich mich noch erinnern kann, war unter anderem die Größe von Monorepos und dann mit CI.
Weil, ja, Wolfgang hat ja auch diese Features erwähnt von GitHub Actions, dass du sagen kann, wenn sich in diesem Folder was geändert hat, dann trigger den Job und so weiter.
Die kamen ja erst später.
Aber es ging ja auch immer damals so, dass wenn du einen Monorepo hattest, dass du das komplette Repository klonen musstest, um den CI Run zu machen.
Vor zehn Jahren.
Und ich habe mal ganz kurz eine Recherche betrieben, dass es nämlich inzwischen Features von Git, sowas wie ein Partial-Clone oder ein Sparse-Checkout gibt, dass du nur einen Subfolder von dem Git-Repository klonen kannst und nicht das ganze Repository.
Und das ist natürlich jetzt super hilfreich in Sachen von Monorepos.
Aber diese Features wurden erst 2018, 2019 bzw.
2020 released.
Also eigentlich vor acht bis sechs Jahren.
Max, wie siehst du das?
Inwieweit haben solche Art von Features Monorepos nochmal ein Boost gegeben, weil ich meine, an Effizienz ist das ja schon nicht zu nicht zu überbieten, oder?
Bei großen Monorepos, dass du nur einen Teil auscheckt und so weiter und so fort.
Ich würde es tatsächlich gar nicht so hoch einschätzen, den Effekt.
Also sowas wie Shallow Clone, auf jeden Fall super wichtig, wenn du ein Monorepo 10.000 Commits hast, dass du ja nicht jedes Mal, wenn du dein CI-Runner das auscheckt, alle 10.000 Commits replayen muss.
Wichtig.
Für so Sachen wie Partial und Clones und Sparse Checkouts, wo ja nur ein Teil des Repos, nicht alle Ordner, sondern nur die Subfolder gekloned werden.
Das ist nicht was, wo ich sehe, dass viele Leute das wirklich brauchen oder verwenden.
Wenn du Google bist, dann bist du irgendwann in der Dimension, wo sowas wichtig ist, wo du auch wirklich an die, ich meine, deswegen reimplementieren ja dann auch solche großen Firmen irgendwie ihre Package Manager und ihre Dinge, weil sie einfach in der einzigartigen Position sind, wo die Assumptions nicht mehr halten.
Wenn du nicht Google bist, dann würde ich mir erstmal keine Sorgen um Git machen.
Es gibt da schon Sachen, die irgendwann irgendwo Probleme bereiten und die werdet ihr sicher lösen, wenn sie kommen.
Aber da würde ich mir erstmal erstmal nicht anfangen, gerum zu experimentieren, bis man wirklich an dem Punkt ist, wo es ganz akute Probleme gibt und den sehe ich tatsächlich auch bei größeren Firmen selten.
Es macht aber Spaß, sich über diese Probleme Gedanken zu machen.
Naja, naja.
Wir haben jetzt eine ganze Menge über die Grundlagen gesprochen.
Wir haben ein bisschen über das Tooling gesprochen.
Und du hattest schon erwähnt, einer der Key-Fragen ist, wenn du dich mit deinen Arbeitskollegen eigentlich gar nicht verträgst und mit denen gar nicht sprechen möchtest, dann lass mal lieber ein Monorepo sein.
Das bringt mich natürlich zu dieser ganzen People-Frage.
Ist die Entscheidung für einen Monorepo eher eine technische Sache?
Oder vielleicht sogar eher eine People-Sache?
Also inwieweit verändert sich denn die tägliche Arbeit von uns allen, wenn wir auf eine Monorepo anstatt auf einem Poly-Repo agieren.
Ich finde, vieles wird massiv simpler.
Also, ich erinnere mich an meinem letzten Job, wo ich keinen Monorepo gab, da waren wir irgendwie Azure DevOps und es gab eine lange Liste an 50 verschiedenen oder keine Ahnung, wie vielen verschiedenen Repos.
Und der Gedanke, dann irgendwas außerhalb meiner Komfortzone zu machen, war ein bisschen gruselig und die Hürde war passiv.
Und das ist was, wo ich ganz klar merke, dass jetzt, wo ich in einer Monorepo arbeite seit ein paar Jahren, dass sich ganz anders anfühlt.
Also diese Mobilität, würde ich sagen, die Mobilität auch in andere Projekte zu kontributeren zu können, was im Backend und im Frontend auf einmal zu lösen.
Solche Sachen, das sind einfach natürlich.
Das ist nicht was, wo ich mir irgendwie so, also klar, ich muss irgendwie ein Verständnis dafür haben und ich muss immer noch, wenn ich ein Problem habe mit der Person reden, die da verantwortlich für ist.
Aber das merke ich schon, dass sie sich massiv ändert.
Die Geschwindigkeit ändert sich auch.
Also dadurch, dass du einfach einen Commit hast, wo du sagst, okay, das ist mein Front-end, meine Backend-Änderung, alles passt zusammen, deployed, fertig.
Es sind ganz viele Probleme, die ich davor wieder mitbekommen habe, an, okay, jetzt müssen wir aber schauen, dass die Leute vom Backend-Team die Änderungen machen, ah, jetzt muss die erstmal hinterherlaufen, ah, die haben gar keine Zeit dafür, ah, okay, jetzt haben sie es endlich gemacht, jetzt müssen wir es deployen, das müssen wir das Timing so und so hinkriegen, ah, muss ich dann irgendwie backwards-compatibility bei mir einbauen und so weiter.
Das ist halt ziemlich anstrengend und das macht dann ja auch viel langsamer.
Weil das ist ja Reibung in jeder Ecke.
Deswegen finde ich, dass sich durch diese zugewinnernde Mobilität und den Zugewinn an Geschwindigkeit sich das Arbeiten schon ganz anders anfühlt, wenn du in einer Firma bist, die dir auf einem Monorepo baut.
Das, was du gerade gesagt hast, bin ich mega-Fan von.
Die Realität zeigt aber ein anderes Bild, meines Erachtens.
Nee, heißt das, zeigt ein anderes Bild?
Nee, es zeichnet.
Die Realität zeichnet ein anderes Bild.
Meine Güte, heute fliegeln aber fliegeln, aber wieder, meine Güte.
Heute fliegen die Floskeln aber wieder und ich kriege sie nicht hin.
Ist egal.
Ich bin mega-Fan von dem, was du erzählst, aber das bedarf auch eine sehr erwachsene Kultur.
Das bedarf eine Kultur des Inner Sources, so nenne ich das.
Open Source in einer in einer geschlossenen Organisation, dass ich mich als Backend-Engineer traue, deinen Frontendcode anzufassen.
Und diese Barriere sehe ich konstant überall.
Es ist auch nicht nur die Barriere, dass du dich traust, sondern dass es die andere Seite erlaubt.
Das ist auch nochmal, dass sich die andere Seite wohl dabei fühlt, dass du jetzt in dem Code vom anderen Team irgendwas machst.
Also ich verstehe das, was du sagst und ich finde das super gut.
Und das ist der, ich glaube, das ist der Kicker fürs Monorepo.
Und ich glaube, mit AI ist diese Polyglot, diese Sprachpolyglot-Thematik auch gelöst.
Ich bin nicht so gut in TypeScript, ja, das kann jetzt DIE.
Dafür bin ich Java-Ingenieur.
Also, das ist das, das ist jetzt keine Ausrede mehr.
Aber der kulturelle Aspekt wird ja nicht von der Igelöst.
Stimmt.
Wie siehst du das?
Es ist ja schon mal auch ein massive Änderung, wenn du den Code einfach siehst.
Ich muss es ja gar nicht jetzt anfangen, anzufassen.
Aber es existiert auch nicht mehr in dieser seltsamen Parallelwelt, von der ich auf jeden Fall die Finger lasse.
Es ist alles da.
In meinem einen Repo, das ich mich lokal mir anschauen kann.
Und der kulturelle Shift dann auch da irgendwie mit anzupacken, der ist viel leichter, wenn man davor schon sich dran gewöhnen konnte und es einfach sieht und es einfach da hat.
Es löst aber keine Organisationsprobleme.
Und das habe ich ja vorhin schon gesagt, wenn Leute sich nicht leiden können, dann werden sie da keinen Spaß dran haben.
Also, das ist schon irgendwas, wo man schauen muss, dass das irgendwie organisch bestimmt, dass die Leute auch Bock drauf haben.
Deswegen alle einfach reinschmeißen in einen Monorepo und sagen, so jetzt werdet ihr ganz viel Mobilität haben und keinen Code mehr duplizieren und ihr werdet euch alle gut vertragen und alles ganz schnell gehen.
Wird vermutlich nicht klappen.
Man muss da schon auch ansetzen, früher und die Leute dazu bringen, miteinander zu reden und schauen, dass der Bayern existiert, weil die Vorteile sind massiv, wenn sie ausgelöst werden.
Aber du kannst halt nicht dazu zwingen, die Vorteile zu sehen.
Sondern du musst es sich irgendwie zeigen und die irgendwie vorleben.
Deswegen bin ich auch so ein Fan von diesem inkrementellen Adaptionsansatz.
Weil dann man es eben schafft, Stück für Stück die Kultur zu demonstrieren, statt sie versuchen, der Organisation überzustüppen.
Hast du da irgendwelche Tipps, wie man die Kultur in diese Richtung reinbringt, wenn du sagst, eben nicht überstülpen, wie so eine Einführung von einem Monorepo?
Wie mache ich denn das dann am besten?
Also man braucht auf jeden Fall irgendwo der, irgendjemanden, der ein Fan von Monorepos ist.
So.
Es ist ja erstmal auch Tooling, Setup-Aufwand und die Vorteile, die kommen im hinteren Ende erst draußen.
Und die werden lange gespürt werden und die werden sich selber potenzieren und sowas, aber erstmal muss es ja auch jemand sein, der irgendwie sich darum kümmert, da so Recherche zu machen und das Tool aufzusetzen und so weiter und so fort.
Deswegen irgendwie einen, ein Team oder eine Person oder eine Gruppe an Leuten identifizieren, die da Bock drauf haben, die da Champion sind und dann eben identifizieren, wo in der Firma das Sinn ergibt.
Kann ich meinen Frontend und mein Designsystem Repo zum Beispiel zusammenlegen in ein Monorepo.
Da muss ich nicht jedes Mal, wenn ich eine kleine Änderung an einem Button habe, erst das Designsystem publishen und dann mir das updaten in meinem Frontend-Repo und dann mir den Button anschauen, dann wieder eine Änderung mache und dann geht es hin und her, sondern ich ändere die eine Datei, schaue meine App an, es sieht alles anders aus.
Schön.
Easy.
Das ist technologisch nicht aufwendig, weil es die gleichen Sprachen sind.
Das sind eh schon Sachen, die direkt voneinander importieren.
Die Leute arbeiten eh miteinander, also die Frontend-Engineers, die Wahrscheinlichkeit, dass sie mit den Leuten vom Designsystem, wenn sie es auch nicht die Komponenten selber schreiben, irgendwie zusammenarbeiten, im Kontakt sind mit denen, ist ja recht hoch.
Da gibt es einfach Sinn.
Und deswegen würde ich sagen, find Leute, die Bock drauf haben, lass sie das Experiment starten.
Und dann, wie schon gesagt, entwickelt es so einen Magnetismus.
Dann werden die anderen Leute auch sehen, dass es Vorteile bringt und dann sich überlegen, ob sie da auch mitmachen wollen.
Und dann wird der Kulturschift irgendwie organisch über die Leute kommen, die sozusagen Stück für Stück reingehen.
Gibt es irgendwelche Anti-Batterns, die du gesehen hast, wo du sagst, okay, auf keinen Fall, weil sonst geht es eben schon auf der technischen Seite schief und dann braucht es gar nicht die kulturelle dazu.
Jegliches Dogma letztlich.
Sagen, es muss jetzt alles sofort.
Es müssen von Anfang an verschiedene Sprachen sein.
Es müssen Teams an die nächste zu tun haben.
Das ist einfach alles kleine Reibung, die das dann dazu führen kann, dass das ganze Projekt einfach fehlschlägt und alle Leute merken, wir haben jetzt diese ganze Arbeit gemacht und mein Leben ist natürlich nicht besser geworden.
Monorepos sind scheiße.
Dabei ist es vielleicht auch einfach, wir haben die Arbeit nicht an der richtigen Stelle angesetzt.
Und vielleicht war es einfach der falsche Implementationsansatz und Monorepos sind gar nicht so schlecht, wie ich denke.
Aber ich meine, ein Risiko kann ja auch sein, und das höre ich gerade so raus, dass Monorepos initial schon mehr Koordinationsaufwand sind.
Man muss sich halt irgendwie auf ein paar Standards einigen, man muss gucken, wie organisiert man den Code, wie verhindert man, dass man irgendwie Code, der nicht zusammenpasst, nicht zusammengelegt wird.
Entwickler und entwicklerin sind ja sehr opinionated.
Sie haben ihre Tools und lieben ihre Setups.
Der eine mag ein Make-File, der andere Nix-Container und Nix-Apps und weißt du, also da gibt es ja gibt es ja super viele Flavors.
Und das ist natürlich schon ein Risiko, dass dieser hohe Koordinationsaufwand, auf dieser hohe Diskussionsaufwand das ganze Projekt auch zum Kippen bringt, oder?
Denn du sagtest zwar, ja, lass uns das Experiment einfach mal starten, aber es kann auch so enden, dass jeder frustriert ist, weil niemand das bekommt, was er oder sie möchte.
Weil niemand möchte seine Babys abgeben.
Auf jeden Fall.
Deswegen hat Google ja auch große Teams, die sich nur darum kümmern, diese Monorepo zu maintainen.
Und deswegen haben viele Firmen ja auch so Plattform-Teams, die genau sich darum kümmern, dass irgendwer auch das ownt, das Ganze.
Die einzelnen Teams wollen sich vielleicht nur um ihr Front-end, ihr Backend ihre Library kümmern und möglichst die Finger von dem Monorepo-Zeug weglassen lassen.
Aber irgendwer muss dafür verantwortlich sein, dass das Tooling Setup ist, dass das Tooling maintained wird, dass irgendwie Probleme, die in den verschiedenen Teams aufkommen, gelöst werden.
Deswegen, es ist auf jeden Fall auch ein Investment.
Also es ist nicht komplett for-free und magisch passiert es einfach.
Tooling wie in X-Store gibt es sich viel Mühe, dass dieser Aufwand möglichst gering ist, dass man eben nicht wie bei Basil Blaze Leute braucht, die Fullzeit-Job es ist, sich da, sich da einzuarbeiten und Stark oder wie auch immer die Sprache heißt, so zu lernen.
So, dass es alles ein bisschen tiefer geht.
Aber es ist auf jeden Fall, da ist auf jeden Fall was dran.
Es ist ein Investment.
Die Sache ist aber, es ist ja kein Investment, das du nur dann hast.
Also dir Gedanken machen über Code-Quality und die Architektur deines Systems und wie das strukturiert ist.
Es musst du dir so oder so.
Du zahlst was, was du dann an anderer Stelle sowieso irgendwie gezahlt hättest.
Also Zahlen sind davon Aufwand.
Aber es ist ein Aufwand, der sich lohnt, weil es um wichtige Sachen geht.
Vor ein paar Jahren hätte ich mir wirklich gewünscht, wir hätten einen Monorepo.
Und zwar habe ich in einer Firma gearbeitet, die hat sehr stark damals auf PHP und Symphony gesetzt und in jedem Package Manager waren strikte Versionsnummern eingetragen, so wie man es ja heute auch macht.
Damals gab es noch kein Depender-Bot und Renovate und allem drum und dran, also Bots sieht das automatisch durchfahren.
Deswegen musstest du Pakete manuell immer noch hochziehen.
Und diese ganze Firma hatte dann ein Logging-Paket über etliche Teams.
Und du kannst dir vorstellen, was das dann immer für eine Malore war, wenn du die Version hochgezogen hast und dann von allen Subdependencies neue Version, äh, neue Releases gemacht hast und so weiter und so fort.
Du warst gefühlt einen halben Tag nur in irgendwelchen 35 Repos unterwegs und warst nur die Version hochgezogen.
Ja, damals war es mir zumindest zu viel Aufwand, irgendein Skript zu schreiben, was dann darüber iteriert und diese Pull-Request automatisch aufmacht.
Heutzutage lacht man da wirklich drüber mit Dependerbot und Renovate und AI und allem drum und dran.
Ah, schreckliche Zeit.
Ich fühle mich, jetzt fühle ich mich wie nach dem Krieg, Wolfgang.
Jetzt fühle ich mich so wie du.
Heute da gelöst ist sowieso alles AI.
Die Plattform-Teams brauchen wir übrigens auch nicht mehr.
Das macht auch AI.
Also, Andis Job als Lead von dem Plattform-Team ist dann sowieso auch obsolet, ganz klar.
Also AI ändert alles.
Aber ihr habt es ja auch eingangs schon erwähnt, AI hat mich zumindest auch wieder an die Monorepos erinnerst.
Max, kannst du uns mal ein Einblick geben, warum dieses AI-Thema jetzt mit Monorepos so zusammenhängt und warum das so wichtig ist oder wichtig geworden ist.
Ich bin übrigens, um ganz zum Anfang zurückzugehen, ich bin schon bei dir, dass du so ein bisschen abgeflaut hat und es irgendwie andere Themen waren, die heißer waren.
Danke, du bist ein guter Gast.
Sorry, Andi.
Ich verstehe da nicht, ich verstehe halt komplett an.
Irgendwie Leute, die südlich von mir wohnen, irgendwie zusammenhalten müssen.
Macht ruhig.
Ja, macht ruhig.
Stell dir vor, du würdest diesen super coolen 10x-Engineer, den du hast, in den Raum setzen und sagen, hier ist eine Datei, die du dir anschauen darfst, jetzt bitte mach die Änderung, die ich möchte in meinem System.
Egal wie klug der ist, wird er halt nicht weit kommen, leider.
Weil viel Kontext fehlt und er nur diese eine Datei ändern kann und nicht irgendwie Zugriff zu dem ganzen anderen Rest des Systems hat.
Und so ähnlich ist es mit AI-Agents und LLM-Tooling an sich, dass je mehr Kontext über das ganze System die zur Verfügung haben, desto besser können die dann auch Änderungen in den System machen.
Und je mehr Zugriff sie haben auf die ganzen verschiedenen Orte, wo der Code definiert ist, desto höher, größer wird deren Autonomie auch ein ganzes Feature zu bauen, statt nur diese eine kleine Änderung in der einen Datei machen.
Copilot gibt es ja schon seit, keine Ahnung, vier Jahren jetzt oder sowas.
Vier, vielleicht sogar mehr Jahren.
Und am Anfang war der Scope halt, diese eine Zeile Code jetzt zu complet.
Und dann war es irgendwann diese eine Funktion.
Und dann gab es irgendwann ein Chatfenster und Cursor konnte in einer einen Datei ein bisschen Zeug rumschreiben.
Und dann gab es Cloud Code und plötzlich konnte man in mehreren Dateien immer größere Sachen bauen.
Also die Scope, in der so AI-Agents sich bewegen, die wächst stetig.
Und wenn du dann, dadurch, dass du nur ein kleines Repo hast, indem nur ein kleiner Teil deines Systems definiert ist, dadurch schränkst du dir ja total ein.
Weil die Modelle sind ziemlich gut mittlerweile und sie werden sicher nur besser werden.
Deswegen ist ein Mono-Repo, was dann eben auch ganz viel enabelt.
Also, ich bin jetzt wirklich kein AI-Researcher, aber warum ich glaube, dass AI im Coding-Bereich auch so weit fortgeschritten ist, ist, dass Code halt so ganz klar semantisch eindeutig definiert ist, was hier passiert, was macht diese Sache, was macht diese Sache, was macht diese Sache, gegenüber, ich habe ein wirres Netzwerk an Menschen, die irgendwie miteinander reden und verschiedene Repos maintainen und dann, wenn ich irgendwas ändern will, dann muss ich diesen einen Typen aus Flack anschreiben.
Und das muss ich halt wissen, weil ich, keine Ahnung, den Leute beim Lunch getroffen habe.
Das ist, was das AI nicht gut kann.
Wenn jetzt aber ich ein Monorepo habe, wo das alles klar definiert ist, wo die AI genau sehen kann, wie hängen all die verschiedenen Sachen voneinander ab, wie mache ich diese eine Änderung und was wird es dann im Impact hier an der anderen Seite?
Das ist natürlich genau die Stärke, die diese Systeme haben.
Dadurch werden sie auch viel größere Änderungen machen können.
Und das ist ja genau das, was wir wollen.
Wir wollen ja, dass, also, das ist jetzt vielleicht eine größere Frage.
Aber grundsätzlich ist es im Interesse des AI-Codings, dass die Agents immer autonomer werden können, damit man bessere, größere Änderungen machen können im ganzen System.
Ganze Thematik mit dem Kontext-Window spielt natürlich auch eine sehr hohe Relevanz, besonders bei einem Mono-Repo.
Klar, ich glaube, wir sind aktuell bei einer Million.
Bedauerlicherweise.
Ich bin mit meinem Opus 4.6 einem Million Code Kontext-Window nicht so happy irgendwie, ich finde die Performance schlechter als davor.
Genau, aber von der Theorie her ein großes Kontext-Window wird ja bei einem großen Mono-Repo ja auch Sinn machen.
Oder?
Ich meine, der Kollege, der Herr oder Frau LLM, fährt sich da eine ganze Menge Code rein, analysiert dann eine Menge Code, summarized vielleicht so ein bisschen.
Besonders wenn du dann nicht nur auf einer Applikation nur auf deinem Java-Backend rumtunst, sondern vielleicht auch noch die neuen APIs in der Mobile oder Flutter-App, die in demselben Repo liegt anpasst, dann noch das Java-Backend und so weiter und so fort, dann muss man natürlich schon ein großes Kontext-Window haben.
Aber es geht ja auch darum, dass du einfach Zugriff auf die Dateien überhaupt hast.
Das heißt ja gar nicht, dass dein Kontext-Window gefüllt wird, aber du kannst überhaupt auf diese Dateien zugreifen.
Wenn du wissen willst, wie ist die Backend-API aufgebaut im Frontend, dann ist halt einfach gut, wenn du die eine Datei, die vielleicht auch ganz kurz ist, halt öffnen kannst.
Weil sonst hat das Frontend-Repo die Informationen gar nicht.
Die kannst du vielleicht einbauen und die kannst du vielleicht auch mit auschecken oder extra mit einem Pfeil dazugeben, aber es ist natürlich alles viel mehr Aufwand.
Und wenn du zum Beispiel im GitHub-Universe arbeitest und dort ein Agent startest, ich glaube ich mittlerweile hat er Zugriff auf mehrere Repos, aber grundsätzlich ist es natürlich auch einfacher, wenn du alles in einem Repo liegen hast und der dann in diesem Kontext schön vor sich hinrattern kann und alles findet, was er braucht.
Es muss nicht unbedingt sehr viel sein, aber das Richtige muss halt verfügbar sein.
Ja, genau.
Würde ich auch nochmal so unterstreichen.
Also dieses Kontext-Window größer, auf jeden Fall besser.
Aber das hat sich ja auch verändert, sagen wir mal, vor zwei Jahren, als ich ChatGPT-Fenster offen hatte, dann habe ich da irgendwie Code reingepastet und gesagt, erklär mir das und das.
Da war diese Kontext-Window-Sache noch viel relevanter, weil es da ja wirklich ein, hier sind all die Dateien, die ich habe, erklär mir irgendwas.
Heutzutage sind so Agents ja super smart, dass sie dann anfangen, sich da die einzelnen Dateien rauszusuchen und dann nur gezielt Sachen auszulesen.
Und das ist ja gar nicht mehr so ein, wir ballern einfach alles ins Kontextfenster und da musst du es auch eine Million Tokens haben, weil sonst passt ein Monorepo da nicht rein, sondern es ist ja viel präziser.
Deswegen würde ich das Kontext-Window und Monorepo-Thema so ein bisschen entkoppeln.
Das ist auch was, was ich vor einer Weile immer wieder gehört habe, so als Gegenargument, so nein, Monorepo ist schlecht, weil die AI ist verwirrt, weil es gibt zu viel Kontext und zu viele Dateien.
Das würde ich sagen, ist heutzutage nicht mehr so.
Das ist kein Problem.
Und dann ist eben der andere Effekt, dass die Agents können auch alles sehen und alles verstehen, alles nachvollziehen, alles recherchieren, von alleine viel wichtiger.
Ich denke jetzt aber auch mal über Elemente nach, wo Monorepos mal jetzt nicht das geschnittenbrot ist, sondern über die Kritik.
Zum Beispiel, es bäckt ja auch Risiken, denn du hast jetzt eine Frontend-App, eine Backend-App und eine Mobile-App in einem Monorepo.
Du machst einen Pull-Request und änderst die Backend-API.
In diesem Pull-Request editierst du ebenfalls die Anbindung der Mobile-App an die neue Backend-API.
Das ist technisch alles super, funktioniert grandios.
Ergibt Sinn bis jetzt.
Ja, ja, er gibt Sinn bis jetzt.
Das ist schon super, was wir uns darauf einigen können.
Jetzt ist es natürlich im Mobile-Sektor so, dass du, zumindest wird das oft nicht gemacht, die Leute, die die Mobile-App installiert haben, nicht auf einen Upd forcieren kannst.
Das bedeutet, alte Versionen sind im Umlauf echt lange.
Und deswegen kannst du diesen harten Cut ja nicht machen.
Also du brauchst ja im Backend die alte Version der API noch, weil du halt alte App-Versionen hast.
Obwohl jetzt gerade, wo ich das, ich mache hier gerade so ein bisschen Rubberducking, weil dieses Risiko hast du in eine Polyglot-Repo natürlich auch.
Ich wollte genau dasselbe fragen, wo ist der Unterschied.
Das Einzige, was mir natürlich einfällt, ist, dass du grundsätzlich die Reviewer dazu brauchst.
Also dass du nicht selber irgendwas durchbuschen darfst, wenn es die Mobile-App zum Beispiel betrifft, sondern dass das Mobile-Team dann dadurch mit eingebunden ist.
Aber das geht ja heutzutage mit Code Ownership eigentlich ganz gut, dass das automatisch gemacht wird.
Und zum Beispiel NX bietet ihr da auch irgend sowas an, dass das quasi auf der Team-Seite irgendwie Verantwortlichkeiten nochmal zusätzlich definiert werden.
Also nächste Tooling, das ich ganz cool finde, dass dieses ganze Ownership-Thema viel einfacher macht, weil man eben sagen kann, ich definiere Ownership in diesem Project Graph zum Beispiel.
Ich sage alle Sachen, die das Backend und damit abhängen, muss ich dieses Team irgendwie ein Review geben, damit es durchkommt.
Oder alle Sachen, die getaggt sind mit dem Thema API, muss diese Person draufschauen.
Das heißt, man muss nicht mehr ein und wir synchronisieren das dann sozusagen in deine Code-Owners-GitHub-File oder wie auch immer das bei Bitbucket und sowas allem heißt, dass du es sozusagen nur einmal zentral deklarieren kannst und wie dann die Textdateien draus machen.
Weil genau, also das ist natürlich ein wichtiges Thema, was auch Leute, das habe ich, glaube ich, vorhin schon angeschnitten, sich Sorgen machen, dass dann plötzlich alle möglichen Leute kommen und irgendwie Code bei ihnen im Projekt reinpushen, der gar nicht, den sie selber gar nicht so verantworten wollen.
Das ist also alles ohne Probleme lösbar.
Man kann immer noch als Team Kontrolle über seine eigenen Code haben.
Und die ganzen Metadaten, die ihr abspeichert in NX, die liegen üblicherweise in Files, wenn ich das richtig verstanden habe, oder?
Genau, also wir haben ein dieses Project Graph-Konzept eben und der wird aus verschiedenen Quellen zusammengebastelt.
Da gibt es Sachen, ich habe irgendwas selber konfiguriert, im Sinne von dieses Projekt hängt von dem Projekt ab.
Aber zum Beispiel gibt es auch Sachen wie, ich habe zentral das Plugin für Gradle definiert.
Und dann, wenn ich verschiedene Gradle-Bild-Files habe, werden die sozusagen automatisch NX-Targets und auch in diesem Project Graph mit eingebunden.
Das sozusagen, wenn ich sage, lass mal alles bauen, dass man dem Bild machen für alles, was sich ändert hat.
Es ist mir erstmal egal, ob das jetzt ein Gradle-Bild ist oder ein Webpack-Bild oder was auch immer.
Sondern es gibt eben so eine Unified CLI, die Leute verwenden können.
Und dieser Project Graph setzt sich eben aus all diesen verschiedenen Sachen zusammen und das ist eine gigantische JSON-Datei, die da irgendwo liegt.
Also der Hintergrund meiner Frage war natürlich auch dahingehend, es ist jetzt nicht irgendeine Plattform in der Cloud, wo ihr irgendwie diese Metadaten speichern, sondern ihr habt es in einem Repository und damit hat auch mein LLM oder mein mein Agent wieder Zugriff auf diese ganzen Metadaten und kann diese Metadaten natürlich auch nochmal mit einbeziehen in diesen ganzen Thinking-Prozess und wie man dann damit umgeht.
Das heißt, ich stelle meinem AI-Agent sogar diese Informationen zur Verfügung auf der Team-Ebene, wer ist für was verantwortlich, muss man irgendwas beachten.
Also da kann sogar in die menschlichen unter Anführungszeichen Strukturen hineingehen und die mitnehmen.
Das ist natürlich auch ein großer Vorteil.
Ja, hätte ich gar nicht hier sein müssen für den Podcast, das hast du selber perfekt perfekt rübergebracht.
Hat ja nichts jetzt nur mit NX zu tun, sondern ganz allgemein.
Also die Tendenz geht ja wieder, muss man ja auch dazu sagen, mehr in diese Richtung.
Weil früher hattest du natürlich dann irgendwelche Jenkins-Definitionen, die sind irgendwo gelegen in irgendeinem anderen Repository und du hattest natürlich diese Infos nicht.
Und umso mehr natürlich im Repository liegt, GitHub-Actions oder sonstige Dinge, umso einfacher ist es natürlich auch, das mit einzubeziehen.
Also für uns Menschen natürlich, aber für die Agents besonders.
Ja, genau.
Was das Bild, was wir da gerne überwenden, ist so Navigieren im Auto zu sitzen und einfach irgendwie raten, wo man hin muss, gegenüber halt Google Maps zu haben und dir ganz klar anschauen können, wo bin ich, wo muss ich hin, wie ist diese ganze Map von meinem Repo sozusagen aufgebaut, macht es natürlich massiv einfacher für Agents und Menschen.
Ich möchte jetzt auch mal eine Lanze brechen für die ganze Jenkins-Crew.
Erstens, ich glaube, ganz viele Firmen nutzen Jenkins noch.
Zweitens, auch bei Jenkins gibt es inzwischen ein Jenkins-File und auch schon echt ein paar Jahre, was du dir jetzt Repo legen kannst.
Also diese Story, die du gerade erzählt hast, tut mir leid, die ist wirklich nicht vom zweiten Weltkrieg.
Ich glaube, die ist vom ersten.
Ja, ja, darum sage ich ja, früher sind diese ganzen Jenkins-Sachen irgendwo anders.
Die sind meistens auch in dem Repo gelegen, aber halt in irgendeinem anderen.
Das war ja immer das Problem.
Also, dass die Daten dann nicht in dem eigentlichen Repo liegen, weil die CICD-Pipelines irgendwo anders definiert waren.
In einem, vielleicht sogar einem Cloud-Tool, aber im besten Fall in einem anderen Repo.
Und das finde ich eigentlich ganz cool, dass das zusammenwächst einfach und dass man alle Informationen an einem Ort hat und das alles sich auch so schleichend Richtung Mono-Repo langsam bewegt hat in den letzten zehn Jahren.
Also der Hype ist vielleicht abgeflacht, aber es ist dann so schleichend immer mehr übergegangen, dass man sich fast so natürlich schon wohlgefühlt hat, da vielleicht Frontend und Backend mal zusammenzulegen in einem Repository.
Und während du gesprochen hast, habe ich natürlich Jenkins gegoogelt, weil ich natürlich die ganze Sache in den Shownotes verlinken möchte.
Und dabei habe ich gesehen, das letzte Jenkins-Release ist keine zwei Wochen alt.
Also das Projekt ist alive and kicking.
Jenkins wurde auch noch viel verwendet, gar keine Frage.
Ich habe übrigens in der Zwischenzeit auch gegoogelt und habt das nochmal gecheckt.
Google ist damals 2015 rausgekommen mit dem Single Monorepo bei Ihnen.
Hatte schon gehört, dass es ein bisschen länger so ist.
Also ich weiß nicht, ob es die erste Erwähnung war, aber es war auf jeden Fall große Story damals, why Google Stores Billions of Lines of Code in a single repository 2015 auf the Scale Conference.
Okay, und das stimmt.
Das Paper wurde im Juni 2016 veröffentlicht.
Das haben wir natürlich auch in den Shownotes verlegt.
Max, vielen lieben Dank für diese Episode.
Jetzt frage ich mich gerade natürlich, wie viele Leute nach dieser Episode die Diskussion mal mit ihrem Steph-Engineer, Teamleiter, Tech-Lead oder Chef generell mal anstoßen.
Hey, ich habe da was gehört.
Dieses Monorepo und AI.
Die beiden lieben sich.
Und wir wollen doch hier auf den Train aufspringen.
Lass uns das doch mal probieren.
Lass uns das nochmal wissen.
Also, ich bin da sehr gespannt, wer vielleicht sogar ein Monorepo in seiner Firma nutzt und wer nicht und wer gerade darüber überlegt.
Oder wem diese Episode diesen Flausen in den Kopf gesetzt hat, die ganze Sache einfach mal zu testen.
Und natürlich sind wir auch immer daran interessiert, Kritik an Monorepo.
Also, was habt ihr euch gedacht, läuft dann besser oder gut, aber was hat sich davon nicht bewahrheitet?
Kommt doch einfach mal in unsere Discord-Community und da bin ich sehr, sehr gespannt auf euer Feedback.
Max, was ist die eine Sache, wirklich, die eine Sache, die sich jeder fragen sollte, bevor man eine Monorepo aufsetzen sollte.
Oder das Experiment starten sollte, so wie du es formuliert hast.
Will ich am Ende des Tages ein bisschen weniger genervt sein?
Das ist die Frage.
Ich sage nicht, dass es Monorepo für jeden perfekt ist, aber ich glaube, viele Leute leiden mehr in ihrer alltäglichen Arbeit auf Softwareentwickler, als sie es müssten.
Und das Experiment starten, das glaube ich, ist echt, das ist für jeden das Richtige.
Hast du auf diese Frage jemals eine Nein-Antwort bekommen?
Will ich jemals, will ich weniger genervt sein?
Nein.
Siehst du?
Dann Monorepos.
Wie immer gilt, falls ihr Feedback zu dieser Episode habt, kommt in die Discord-Community, nennt uns das, wir leiten das gerne an den Max weiter.
Wir haben natürlich auch in den Shownotes ein paar Links hinterlegt, zum Beispiel von NX haben wir ein bisschen drüber gesprochen, von der Monorepos.tools Webseite, wer vielleicht ein bisschen mehr Informationen über Monorepos und die entsprechenden Tools für eure Sprache habt.
Turbo Repo wird zum Beispiel für JavaScript und TypeScript erwähnt.
Aber wir haben auch über Basil und natürlich auch Wolfgangs Lieblingsto-Tool Jenkins gesprochen.
Haben wir natürlich auch verlinkt, falls ihr das neueste Release downloaden wollte.
Ansonsten würde ich sagen, Max, vielen lieben Dank für deine Zeit.
Und ich verabschiede mich im Namen von allen drei.
Ich hoffe, die sagen euch auch nochmal Tschüss.
Und sonst würde ich sagen, bis zur nächsten Episode und Tschüss.
Ja, danke euch.
Ich hatte viel Spaß.
Ciao.
Servus.