Belajar Microfrontend - Monorepo Scaling: Nx/Turborepo & Caching

#Pendahuluan

Ketika microfrontend tumbuh, kalian akan punya banyak app dan package dalam satu repo. Tanpa tooling monorepo yang tepat, kemampuan "hanya build yang berubah" hilang, dan CI jadi lambat karena mengulang build semua app. Di episode ini kita membahas Nx dan Turborepo untuk menskalakan monorepo.

Mengapa penting? Karena microfrontend bergantung pada banyak build independen. Tooling monorepo yang baik membuat build, test, dan cache menjadi cepat — investasi yang langsung terasa saat jumlah tim dan app bertambah.

#Monorepo Tools

#pnpm Workspaces (Dasar)

Fondasi kita (sejak episode 3) adalah pnpm workspaces — pengelola install dan workspace. pnpm sudah menyediakan instalasi efisien & isolasi dependency.

#Turborepo — Task Caching

Turborepo menambahkan task caching di atas pnpm. Ia memahami task graph (build, test per app) dan menyimpan hasil — task yang input-nya tidak berubah di-skip (cache hit):

turbo.json (ringkas)

{
  "tasks": {
    "build": {
      "dependsOn": ["^build"],
      "outputs": ["dist/**"]
    },
    "test": {
      "dependsOn": ["^test"]
    }
  }
}

#Nx — Dependency Graph & Affected Builds

Nx menyediakan dependency graph penuh dan affected builds: ia tahu persis app/package mana yang terdampak perubahan, lalu hanya membangun yang terdampak:

Hanya build app yang terdampak

nx affected:build --base=main

Nx juga punya generators untuk menambah app/package secara konsisten.

#Affected Builds

Konsep inti: saat PR mengubah packages/design-system, hanya app yang bergantung padanya (yang berubah) yang perlu di-build ulang. App yang tidak terdampak memakai hasil cache.

Di CI, hanya build affected

pnpm exec nx affected:test
pnpm exec nx affected:build

Ini memangkas durasi CI drastis — alih-alih membangun 6 remote, hanya 1-2 yang di-build.

#Remote Cache

Nx/Turborepo mendukung remote cache di CI: hasil build disimpan di server cache bersama. Jika developer/CI lain mem-build task yang sama (input identik), mereka mendapat hasil dari cache, bukan mengulang build — sering kali menjadi fraction of seconds.

Remote cache Turborepo

{
  "remoteCache": {
    "enabled": true
  }
}

Remote cache adalah pengganda kecepatan untuk tim multi-engineer yang sering mengerjakan task sama.

#Standalone Project vs Monorepo

Aspek	Monorepo	Standalone (banyak repo)
Kolaborasi lintas tim	Mudah (satu repo)	Terkait bergantung repo lain
Shared packages (design-system)	Alami (workspace)	Butuh publish npm
Rebuild	Tooling afected/cache	Per-repo CI
Permission/ownership	Lebih sulit (limited)	Mudah per-repo

Di 2026, monorepo adalah pilihan default untuk microfrontend — terutama karena shared packages (design-system, shared-state) dan kemampuan affected build. Standalone tetap masuk akal untuk organisasi dengan repository-isolation yang ketat.

Note

Mulai dari pnpm workspaces + Turborepo yang ringan. Tambah Nx jika butuh dependency graph yang lebih dalam dan generators. Hindari overweight tooling sebelum masalahnya benar-benar muncul.

#Penutup

Pada episode 19 ini, kalian telah memahami monorepo scaling.

Inti yang harus dibawa pulang:

pnpm workspaces sebagai dasar; Turborepo untuk task caching.
Nx untuk dependency graph & affected builds — hanya build yang terdampak.
Remote cache di CI → build sepersekian detik, hemat sumber daya.
Monorepo adalah default 2026 untuk shared packages + affected build; standalone untuk kebutuhan isolasi ketat.

Di episode 20 selanjutnya, kita akan membahas testing microfrontend — unit test per remote, integration test host + remote dengan mocks, contract test props/events, visual regression, dan cara men-stub remote saat test host. Pastikan monorepo kalian cepat!