Belajar Microfrontend - Konsep Dasar & Arsitektur Utama
Membedah model lapisan host (shell), remotes, dan shared dependencies, tiga strategi integrasi (build-time, run-time, server-side), dua pendekatan utama 2026 yaitu Module Federation 2.0 dan single-spa, serta trade-off dan kapan tidak perlu memakai microfrontend.
#Pendahuluan
Setelah di episode 1 kita memahami sejarah dan alasan mengapa microfrontend ada, pada episode ini kita masuk ke conceptual model-nya: komponen-komponen arsitektur dan cara mereka berintegrasi. Ini fondasi berpikir yang akan dipakai di seluruh series.
Mengapa episode ini penting? Karena banyak orang terjun langsung ke kode Module Federation tanpa memahami lapisan abstraksinya. Alhasil mereka membangun remote yang terlampau banyak, berbagi dependency yang salah, atau memilih pendekatan yang keliru. Memahami lapisan host/remote/shared serta tiga strategi integrasi akan membuat keputusan arsitektur kalian matang.
#Model Lapisan
Setiap arsitektur microfrontend terdiri dari tiga peran utama:
#Host (Shell)
Host (atau shell) adalah aplikasi container: ia memegang navigation, layout, dan routing top-level. Hostlah yang memutuskan remote mana yang dimuat pada rute tertentu. Contoh: shell menampilkan header + sidebar, lalu merender remote catalog saat user mengunjungi /catalog.
#Remotes
Remotes adalah aplikasi independen yang mengekspos komponen atau halaman untuk dimuat host saat runtime. Contoh: catalog mengekspos ./CatalogApp, product-detail mengekspos ./ProductDetailApp. Remote boleh punya router dan state internal sendiri, tetapi struktur halaman keseluruhan dikendalikan host.
#Shared Dependencies
Shared dependencies adalah library yang dipakai bersama agar tidak diduplikasi — yang paling penting react dan react-dom. Jika dua React ter-load dalam satu halaman, hook akan error ("invalid hook call"). Di episode 5 kita bahas singleton dan versioning secara mendalam.
#Strategi Integrasi
Ada tiga strategi dasar untuk menggabungkan frontend:
#Build-Time
Integrasi lewat npm package: remote dikemas sebagai library dan dipasang host sebagai dependency. Mudah dan type-safe, tetapi rilis terkunci — setiap kali remote berubah, host harus di-build ulang dan di-deploy ulang. Ini sebenarnya masih monolit dalam kemasan package.
#Run-Time
Integrasi saat runtime: host memuat module remote dari URL (CDN) saat user browsing. Inilah inti Module Federation dan single-spa. Remote bisa di-deploy independen; versi lama host dan versi baru remote bisa hidup berdampingan.
#Server-Side
Server-side composition: server (bukan browser) yang menggabungkan fragment/HTML dari tiap app. Paling independen, tetapi menuntut backend/edge yang canggih. Kita bahas pola Podium dan Next.js SSR di episode 22.
#Dua Pendekatan Utama 2026
#Module Federation 2.0
Module Federation 2.0 adalah pendekatan build-level federation: setiap remote di-bundle sebagai module, lalu host memuatnya via runtime. Keunggulannya di 2026:
- TypeScript type-safe (
dts: true). - Shared dependency otomatis dan tree-shaking.
- Dynamic federation (
loadRemote). - Cocok untuk satu framework (kebanyakan React).
Ini menjadi rekomendasi default untuk mayoritas kasus.
#single-spa
single-spa adalah pendekatan framework-level: ia memuat aplikasi lengkap (bukan module) via lifecycle bootstrap/mount/unmount. Keunggulannya:
- Polyglot: React + Vue + Angular hidup berdampingan dalam satu halaman.
- Cocok untuk organisasi yang punya banyak framework legacy + baru.
Trade-off: setup lebih complex, shared dependency manual, tanpa type-safety otomatis. Kita bandingkan mendalam di episode 11.
#Trade-off & Kapan Tidak Perlu Microfrontend
Microfrontend adalah distributed system di sisi frontend — ia membawa seluruh trade-off distribusi: network load tambahan, error remote yang harus ditangani, dan version skew antara host dan remote yang berjalan di versi berbeda.
Karena itu, jangan pakai microfrontend jika:
- Aplikasi kecil (kurang dari ~20 halaman) atau satu tim tunggal.
- Kebutuhan performa realtime yang ketat di satu alur (overhead pemuatan remote menambah latensi).
- Tim belum siap menangani operasional distributed system di depan.
Important
Aturan praktis: microfrontend memecahkan masalah organisasi (skala tim, independensi rilis), bukan masalah teknis semata. Kalau tidak ada masalah skala tim, microfrontend menambah kompleksitas tanpa imbalan.
#Penutup
Pada episode 2 ini, kalian telah memahami arsitektur konseptual microfrontend: lapisan host, remote, dan shared dependencies; tiga strategi integrasi; dua pendekatan utama 2026; dan trade-off ketika tidak perlu menggunakannya.
Inti yang harus dibawa pulang:
- Host pegang navigasi/layout/routing; remote punya domain sendiri; shared dependencies mencegah duplikasi React.
- Tiga strategi integrasi: build-time (npm, rilis terkunci), run-time (MF/single-spa, rilis independen), server-side (gabungan fragment di server).
- Module Federation 2.0 = build-level, type-safe, satu framework → default; single-spa = framework-level, polyglot.
- Microfrontend adalah distributed system di frontend: hindari untuk aplikasi kecil/tim tunggal/performan realtime ketat.
Di episode 3 selanjutnya, kita mulai hands-on dengan membangun arsitektur studi kasus storefront (Tokoku) — struktur monorepo pnpm dengan shell + lim enam remotes + design-system, dan alur dev-nya. Pastikan environment episode 0 siap, karena kita mulai menulis kode nyata!