Apa itu strategi monorepo vs polyrepo?

Question

Accepted Answer

**Monorepo** (satu repositori untuk banyak proyek/layanan) dan **polyrepo** (repositori terpisah per proyek) adalah dua strategi untuk mengorganisir kode di seluruh beberapa proyek. Masing-masing memiliki trade-off signifikan yang mempengaruhi kolaborasi, tooling, dan scaling — memahami keduanya menginformasikan keputusan arsitektur penting.

## Monorepo — satu repo untuk semuanya

```text
Many projects/services/libraries in a SINGLE repository:
  ✓ SHARED code/libraries easy to use and refactor (one place, atomic changes)
  ✓ ATOMIC commits across projects (change an API and all its consumers together)
  ✓ Unified tooling, versioning, CI; consistent standards; easy cross-project visibility
  ✓ Simplified dependency management (one version of shared code)
  ✗ Repo can get HUGE (needs scaling tooling — sparse checkout, build caching)
  ✗ Needs sophisticated build/CI tooling (Nx, Turborepo, Bazel) to be efficient
  ✗ Broad access; CI must be smart (only build what changed)
→ Used by Google, Meta, etc. (with heavy tooling investment).
```

## Polyrepo — satu repo per proyek

```text
Each project/service/library in its OWN repository:
  ✓ Clear OWNERSHIP and boundaries; independent versioning/releases/CI
  ✓ Smaller, focused repos; granular access control; independent teams
  ✗ SHARED code is harder (publish/consume packages; version coordination)
  ✗ Cross-cutting changes span MANY repos (coordinate multiple PRs — painful)
  ✗ Potential inconsistency across repos (tooling, standards drift)
→ Common default; fits independent services/teams.
```

## Memilih

```text
MONOREPO → tightly-coupled projects, heavy code sharing, want atomic cross-project
  changes and unified tooling, willing to invest in scaling tooling
POLYREPO → independent projects/teams, clear boundaries, independent release cycles,
  simpler per-repo needs
→ No universal answer; depends on the org, coupling, scale, and tooling investment.
```

## Mengapa ini penting

Memahami strategi monorepo vs polyrepo adalah pengetahuan tingkat senior yang berharga untuk **membuat keputusan arsitektur yang solid tentang organisasi kode**, sebuah pilihan signifikan dengan implikasi luas, sehingga berguna untuk peran senior/arsitektur.

Kedua pendekatan — **monorepo** (banyak proyek dalam satu repositori) dan **polyrepo** (repositori terpisah per proyek) — merepresentasikan filosofi organisasi yang fundamentally berbeda dengan trade-off nyata. Keuntungan **monorepo** (kode bersama dan refactoring yang mudah, **atomic cross-project commits** — mengubah API dan semua konsumennya bersama-sama, tooling dan standar terpadu, manajemen dependency yang disederhanakan) membuatnya powerful untuk proyek yang tightly-coupled dengan code sharing yang besar, tetapi memerlukan investasi signifikan dalam **scaling tooling** (Nx, Turborepo, Bazel, sparse checkout, smart CI) untuk menangani repositori besar secara efisien. Keuntungan **polyrepo** (ownership dan boundaries yang jelas, versioning independen dan release cycles, repos yang lebih kecil dan fokus, akses granular) cocok untuk proyek independen dan tim, tetapi membuat **shared code lebih sulit** (publishing/consuming packages, koordinasi versi) dan **cross-cutting changes menyakitkan** (mengkoordinasikan PR di banyak repos).

Memahami trade-off ini dan cara **memilih** (monorepo untuk proyek yang tightly-coupled, code-sharing yang bersedia berinvestasi dalam tooling; polyrepo untuk proyek independen dan tim dengan boundaries yang jelas) mencerminkan judgment arsitektur yang diharapkan di level senior — mengenali bahwa tidak ada jawaban universal dan pilihan yang tepat tergantung pada coupling, scale, struktur tim, dan investasi tooling.

Karena organisasi kode di seluruh beberapa proyek adalah keputusan arsitektur signifikan yang mempengaruhi kolaborasi, tooling, scaling, dan otonomi tim, dan karena memahami trade-off monorepo/polyrepo menginformasikan pilihan consequential ini, memahami strategi monorepo vs polyrepo adalah pengetahuan tingkat senior yang berharga untuk pengambilan keputusan arsitektur, sebuah topik yang sering diperdebatkan di mana memahami trade-off (bukan secara dogmatis mendukung satu) mencerminkan judgment matang yang diharapkan untuk peran senior yang membentuk bagaimana organisasi menyusun kodnya.