Belajar Microfrontend - Versioning, Compatibility & Upgrade di Skala Tim

#Pendahuluan

Di skala organisasi besar, microfrontend berjalan karena banyak tim bekerja secara bersamaan pada satu produk. Untuk itu diperlukan kesepakatan tentang kontrak antar remote dan cara menangani version skew — kondisi di mana host lama bertemu remote baru atau sebaliknya.

Mengapa penting? Karena independent deploy berarti komponen di versi berbeda akan hidup berdampingan. Tanpa strategi kompatibilitas, satu rilis remote bisa merusak host atau remote lain yang belum diperbarui.

#Multiple Tim Kolaborasi

#Squad Pemilik Remote

Setiap remote dimiliki satu squad (tim). Tim catalog memiliki catalog dari kode sampai backend, dan bertanggung jawab menjaga kontraknya agar tidak memecah konsumen.

#Contract API Antar Remote (Props) dengan Semver

Antar remote, "API" mereka adalah props (data yang diterima) dan events (yang dipublikasikan) — bukan function signature biasa. Kontrak ini harus di-version-kan dengan semver:

• Breaking (major) — perubahan props/events yang tidak kompatibel (misal menghapus prop, mengubah bentuk payload).
• Non-breaking (minor/patch) — penambahan props opsional, perbaikan.

Tim pemilik remote harus mendokumentasikan kontraknya (interface TypeScript + petunjuk semver) agar konsumen tahu kapan harus upgrade.

#Version Skew

Karena host dan remote rilis pada jadwal berbeda, kita sering punya host lama + remote baru (atau sebaliknya). Kuncinya: backward compatible API.

• Remote baru harus tetap bisa di-load host lama → jangan hapus prop/event yang sudah dipakai konsumen lama secara mendadak.
• Test contract antar versi — pastikan host v1 + remote v2 tetap berfungsi (detail contract testing di episode 20).

#Canary / Feature Flag Remote

Untuk mengurangi risiko, rilis remote bisa melalui canary — deploy versi baru hanya untuk sebagian user:

1. Deploy remote baru (manifest/versi) di belakang feature flag untuk sebagian kecil user.
2. Amati observability (error rate, KPI episode 16).
3. Jika sehat → perluas ke semua user (general release).
4. Jika error → rollback instant (kembalikan flag/manifest).

Feature flag remote memungkinkan pembalikan cepat tanpa rebuild, dan memisahkan "deploy" dari "release".

#Tooling

#Version-Safe Imports via requiredVersion

Seperti episode 5, requiredVersion di shared config memberi batasan kompatibilitas:

shared: {
  react: { singleton: true, requiredVersion: '^19.0.0' },
}

Ini melindungi dari memakai versi library yang tidak kompatibel.

#Compatibility Matrix

Dokumentasikan matrix kompatibilitas — versi host vs versi remote mana yang diuji dan aman:

Matrix ini menjadi referensi tim saat memutuskan jendela upgrade dan batas kompatibilitas.

#Penutup

Pada episode 17 ini, kalian telah memahami versioning & compatibility di skala tim.

Inti yang harus dibawa pulang:

• Setiap remote di-own satu squad; kontrak props/events di-version-kan semver.
• Version skew diatasi dengan backward-compatible API + contract test.
• Canary + feature flag memisahkan deploy dari release; rollback instant.
• Tooling: requiredVersion + compatibility matrix terdokumentasi.

Di episode 18 selanjutnya, kita akan membahas state sharing lanjutan: events & stores — event bus pattern dengan dokumen kontrak event, central store di host dengan useSyncExternalStore, sinkronisasi remote store, dan anti-pattern berbagi React context lintas remote. Pastikan versioning kalian aman!