Belajar Microfrontend - Pattern Migrasi: Monolith SPA ke MF
Membedah migrasi monolith SPA ke microfrontend dengan pola strangler fig: pemisahan shell dulu lalu satu per satu remote, trajectori shared dependency, kriteria kelayakan masuk MF, dan pitfall membuat terlalu banyak remote untuk aplikasi yang tak terlalu besar.
#Pendahuluan
Banyak tim tidak memulai dari nol — mereka punya monolith SPA yang besar dan ingin memigrasinya ke microfrontend. Migrasi ini sensitif: dilakukan serampangan bisa menghentikan pengembangan fitur baru selama berbulan-bulan. Episode ini membahas pola strangler fig — migrasi bertahap yang aman.
Mengapa penting? Karena kebanyakan kasus nyata adalah migrasi, bukan greenfield. Pola yang benar memungkinkan biaya migrasi tersebar dalam waktu, bukan ongkos besar di muka.
#Strangler Fig Migration
Ide strangler fig (dipinjam dari microservices): secara bertahap menggantikan bagian monolith dengan unit baru, tanpa mematikan keseluruhan sistem.
#Pisahkan 1 Halaman ke Remote Baru
Mulai dari satu halaman (misal /catalog): pindahkan ke remote baru, sisanya tetap di monolith. Host (shell) mulai memuat /catalog dari remote, sementara route lain masih monolith lama.
#Bertahap: Shell Dulu, Lalu Satu per Satu Remote
Urutan yang disarankan:
- Bangun shell dulu — siapkan layout, routing, dan kemampuan memuat remote.
- Monolith menjadi "remote sementara" (atau host memuatnya).
- Pindahkan halaman satu per satu ke remote — mulai dari yang paling independen / jarang berubah.
- Teruskan sampai monolith habis ter-urai.
Dengan ini, nilai dirasakan sejak awal (satu halaman sudah independen), bukan hanya di akhir.
#Shared Dep Trajectory
Pemindahan tidak berarti mengubah teknologi sekaligus. Kendalikan trajectori shared dependency:
- Satu React tetap — jangan biarkan muncul React multi-versi di remote-remote baru.
- Upgrade bertahap — naikkan versi React/dependency di jendela yang terencana, bukan serempak.
Ini menjaga singleton React (episode 5) tetap sehat selama migrasi, dan menghindari "dua React" yang muncul saat pindah satu per satu.
Warning
Selama migrasi, pastikan setiap remote baru memakai shared React yang sama dengan host. Lonjakan "invalid hook call" sering terjadi justru saat migrasi karena remote baru membawa React sendiri secara tak sengaja.
#Trade-off Kapasitas: Kapan Layak Masuk MF
Jangan memigrasi hanya karena tren. Tetapkan kriteria masuk microfrontend:
- Tim banyak — berapa tim yang menyentuh satu frontend? Banyak tim → MF bermanfaat.
- Volume tinggi — aplikasi dengan banyak rilis/hari dan banyak developer.
Jika belum memenuhi kriteria (tim kecil, rilis jarang), tunda migrasi — biaya MF (distribusi, operasional) tidak sebanding.
#Pitfall: Jangan Buat Terlalu Banyak Remote
Pitfall klasik: membuat 50 remote untuk 10 halaman. Setiap remote membawa overhead — load, config, deploy, observability. Remote yang terlalu banyak memperlambat dan menyulitkan.
Aturan pragmatis:
- Satu remote per domain/tim, bukan per halaman.
- Hanya buat remote baru jika ada tim/ownership yang jelas.
- Ingat: contract memory, bundle size, tooling complexity bertambah seiring jumlah remote.
Important
Microfrontend yang baik adalah sedikit remote yang besar dan bermakna (per domain), bukan banyak remote kecil. Mulai dengan 1 shell + beberapa remote domain, bukan puluhan halaman terpisah.
#Penutup
Pada episode 25 ini, kalian telah memahami pola migrasi monolith ke microfrontend.
Inti yang harus dibawa pulang:
- Strangler fig: ganti bertahap, satu halaman → satu remote; shell dulu, remote satu per satu.
- Kendalikan trajectori shared dep: satu React, upgrade bertahap.
- Tetapkan kriteria masuk MF (tim banyak/volume tinggi); tunda bila tidak memenuhi.
- Pitfall: jangan 50 remote untuk 10 halaman — satu remote per domain dengan ownership jelas.
Di episode 26 selanjutnya, kita akan membahas troubleshooting & common issues — remote error load, React duplikat, version mismatch, CSS/layout collision, route 404, dan performa buruk saat remote load. Pastikan migrasi kalian aman!