1~
2Bei komplexeren Softwareprojekten kann die Wahl zwischen Monorepo und Polyrepo einen erheblichen Einfluss auf die Produktivität des Teams und die Skalierbarkeit des Codes haben. In diesem Artikel analysieren wir die Unterschiede, Vor- und Nachteile beider Ansätze und helfen dir, die richtige Entscheidung zu treffen.
3~
4## Was sind Monorepo und Polyrepo?
5~
6### Monorepo
7~
8Ein **Monorepo** (monolithisches Repository) ist ein einziges Repository, das den Quellcode mehrerer Projekte, Dienste oder Pakete enthält, die oft miteinander verbunden sind.
9~
10```plaintext filename="Beispiel Monorepo-Struktur"
11my-monorepo/
12  packages/
13    frontend/
14    backend/
15    shared/
16  package.json
17  turbo.json
18```
19~
20### Polyrepo
21~
22Ein **Polyrepo** (mehrere Repositories) bedeutet, dass jedes Projekt, jeder Dienst oder jedes Paket sein eigenes separates Repository hat.
23~
24```plaintext filename="Beispiel Polyrepo-Struktur"
25repos/
26  frontend/
27    package.json
28  backend/
29    package.json
30  shared/
31    package.json
32```
33~
34## Visueller Unterschied
35~
36```mermaid
37flowchart TD
38    subgraph Monorepo
39        A1["frontend/"]
40        A2["backend/"]
41        A3["shared/"]
42    end
43    style Monorepo fill:#e0e7ff,stroke:#6366f1,stroke-width:2px
44```
45~
46```mermaid
47flowchart TD
48    subgraph Polyrepo
49        B1["frontend repo"]
50        B2["backend repo"]
51        B3["shared repo"]
52    end
53    style Polyrepo fill:#fee2e2,stroke:#ef4444,stroke-width:2px
54```
55~
56## Vor- und Nachteile
57~
58### Monorepo
59~
60**Vorteile:**
61- Erleichtert die gemeinsame Nutzung von Code (z.B. gemeinsame Bibliotheken).
62- Atomare Refactorings über mehrere Projekte hinweg.
63- Zentrale Verwaltung von Abhängigkeiten und Konfigurationen.
64~
65**Nachteile:**
66- Kann mit wachsendem Codeumfang schwerfällig werden.
67- Benötigt Tools zur Verwaltung von Teil-Builds/Tests (z.B. Nx, Turborepo).
68~
69### Polyrepo
70~
71**Vorteile:**
72- Jedes Team/Projekt ist unabhängig.
73- Für kleine Projekte leichter zu verwalten.
74- Ermöglicht granulare Zugriffspolicen.
75~
76**Nachteile:**
77- Gemeinsame Nutzung von Code ist schwieriger, ohne Pakete zu veröffentlichen.
78- Refactorings über mehrere Repos hinweg sind komplexer.
79- Mögliche Duplizierung von Konfigurationen.
80~
81## Praxisbeispiel: Monorepo mit Turborepo
82~
83Angenommen, du möchtest ein Monorepo mit Frontend und Backend mithilfe von Turborepo erstellen.
84~
85### 1. Monorepo initialisieren
86~
87```bash
88npx create-turbo@latest
89```
90~
91### 2. Typische Struktur
92~
93```plaintext
94my-monorepo/
95  apps/
96    web/        # Frontend Next.js
97    api/        # Backend Node.js/Express
98  packages/
99    ui/         # Gemeinsame Komponentenbibliothek
100    utils/      # Gemeinsame Funktionen
101  turbo.json
102  package.json
103```
104~
105### 3. Beispiel-Workspace in `package.json`
106~
107```json
108{
109  "private": true,
110  "workspaces": [
111    "apps/*",
112    "packages/*"
113  ]
114}
115```
116~
117### 4. Beispiel für den Import einer gemeinsamen Bibliothek
118~
119Angenommen, du hast eine Funktion in `packages/utils/src/formatDate.ts`:
120~
121```ts
122// packages/utils/src/formatDate.ts
123export function formatDate(date: Date): string {
124  return date.toLocaleDateString('de-DE');
125}
126```
127~
128Im Frontend:
129~
130```ts
131// apps/web/pages/index.tsx
132import { formatDate } from '@myorg/utils';
133~
134export default function Home() {
135  return <div>Heute ist {formatDate(new Date())}</div>;
136}
137```
138~
139## Wann sollte man Monorepo wählen?
140~
141- Mittelgroße bis große Teams, die an mehreren zusammenhängenden Projekten arbeiten.
142- Notwendigkeit, Code zu teilen und großflächige Refactorings durchzuführen.
143- Projekte, die schnell wachsen und optimierte Builds/Tests benötigen.
144~
145## Wann sollte man Polyrepo wählen?
146~
147- Kleine oder unabhängige Projekte.
148- Getrennte Teams, die an unterschiedlichen Produkten arbeiten.
149- Sehr restriktive Zugriffspolicen.
150~
151## Fazit
152~
153Es gibt keine perfekte Lösung für alle. Die Wahl hängt von der Teamgröße, der Komplexität der Projekte und den Anforderungen an die Zusammenarbeit ab. Wichtig ist, sich der jeweiligen Kompromisse bewusst zu sein und die richtigen Werkzeuge zur Bewältigung der Komplexität zu wählen.