Microfrontend Design Pattern: Module Federation v1.5 vs v2.0

Microfrontend (MF) memungkinkan aplikasi besar dibagi menjadi beberapa modul kecil yang dapat dikembangkan, dibangun, dan dideploy secara independen. Module Federation adalah solusi populer untuk MF di ekosistem Webpack/Rspack. Berikut ini eksplorasi untuk dua versi: v1.5 dan v2.0. menggunakan Rspack, React, TypeScript, dan pnpm.

1. Struktur Proyek

Monorepo kita kira-kira seperti ini:

rspack-mf-v1.5-v2.0/
│
├─ rspack-mf-v1.5/
│   ├─ apps/
│   │   ├─ shell-app/
│   │   ├─ profile-app/
│   │   └─ dashboard-app/
│   └─ package.json
│
├─ rspack-mf-v2.0/
│   ├─ apps/
│   │   ├─ shell-app/
│   │   ├─ profile-app/
│   │   └─ dashboard-app/
│   └─ package.json
│
└─ README.md

Keterangan:

• shell-app → host container, lazy-load komponen dari remote
• profile-app → remote app dengan ProfileCard dan shared store
• dashboard-app → remote app dengan DashboardPanel, bisa mengakses store remote lain

2. Module Federation v1.5

Konsep

• Host (shell-app) mengimpor remote components secara lazy-load
• Remote apps expose komponen & state tertentu
• Suspense digunakan untuk fallback saat loading komponen remote

Diagram Pattern: Module Federation v1.5

Shell App (Host, 3001)
 ┌───────────────────┐
 │ ProfileCard │<─── Profile App (3002)
 │ DashboardPanel │<─── Dashboard App (3003)
 └───────────────────┘

             ┌────────────────────┐
             │   Shell App (Host) │
             │   port: 3001       │
             │───────────────────│
             │ <Suspense>         │
             │ ProfileCard        │<───┐
             │ DashboardPanel     │    │
             └───────────────────┘    │
                                       │
            ┌───────────────────┐      │
            │ Profile App       │      │
            │ port: 3002        │      │
            │ exposes:          │      │
            │ - ProfileCard     │─────┘
            │ - store/userStore │
            └───────────────────┘

            ┌───────────────────┐
            │ Dashboard App     │
            │ port: 3003        │
            │ exposes:          │
            │ - DashboardPanel  │
            │ remotes:          │
            │ - profile_app     │
            └───────────────────┘

Keterangan:

• Shell App sebagai host container, lazy-load remote components
• Profile App expose ProfileCard dan Zustand store
• Dashboard App expose DashboardPanel, bisa mengakses store dari Profile App
• Suspense fallback digunakan untuk mencegah layar kosong saat lazy-loading

Di versi 1.5, setup cukup cepat dan sederhana. Fokus utama adalah membuat host bisa load remote secara runtime. Federated types tidak otomatis, jadi dev harus hati-hati dengan type sharing.

2. Module Federation v2.0

Konsep

Sama seperti v1.5, tapi ada beberapa penambahan:

• Federated types otomatis dibuat → type-safe
• Manifest plugin lebih robust → path module remote selalu tepat
• Bootstrap init lebih verbose: host harus init remotes sebelum render
• Tujuannya: membuat integrasi modul lebih aman dan scalable

Diagram Pattern: Module Federation v2.0

         Shell App (Host, 3001)
         ┌───────────────────────────┐
         │ <Suspense> ProfileCard     │<─── Profile App (3002)
         │ <Suspense> DashboardPanel  │<─── Dashboard App (3003)
         └───────────────────────────┘

             ┌───────────────────────────┐
             │      Shell App (Host)      │
             │        port: 3001          │
             │───────────────────────────│
             │ <Suspense>                 │
             │ ProfileCard (Lazy)         │<───┐
             │ DashboardPanel (Lazy)      │    │
             └───────────────────────────┘    │
                                               │
             ┌───────────────────────────┐     │
             │      Profile App           │     │
             │        port: 3002          │     │
             │ exposes:                   │     │
             │ - ProfileCard              │─────┘
             │ - store/userStore          │
             └───────────────────────────┘

             ┌───────────────────────────┐
             │     Dashboard App          │
             │        port: 3003          │
             │ exposes:                   │
             │ - DashboardPanel           │
             │ remotes:                   │
             │ - profile_app              │
             └───────────────────────────┘

Keterangan:

• ModuleFederationPlugin handle sisa lazy-load
• Lazy-loading dan Suspense tetap penting
• Federated types otomatis di-generate → type-safe integration
• Manifest plugin v2.0 memastikan remote module selalu resolve dengan path yang benar
• Setup lebih verbose karena harus meng-initialize remotes di bootstrap, dan konfigurasi DTS lebih kompleks

Secara subjektif berdasarkan pengembanagan saya pribadi, v2.0 setup lebih lama dan verbose dibanding v1.5. Tapi hasilnya lebih stabil, type-safe, dan fleksibel untuk proyek besar.

3. Perbandingan MF v1.5 vs v2.0

Aspek MF v1.5 MF v2.0 Setup bootstrap/init Cepat, simple Lebih panjang, manual init remotes Federated types Minimal, manual Auto-generate, lebih type-safe Lazy-loading remote modules Basic, runtime simple Enhanced, lebih stabil saat remote berubah Manifest & path handling Simpel Auto path resolution, lebih robust Development feel Cepat, langsung jalan Setup lebih lama, verbose, tapi aman Best use case Proyek kecil/medium Proyek besar/kompleks, type-safe

Catatan pribadi: Secara subjektif, MF v2.0 setup lebih panjang dan verbose dibanding v1.5, tapi memberi fleksibilitas dan keamanan lebih tinggi untuk aplikasi kompleks, terutama untuk lazy-loading type-safe dan shared state management.

4. Ringkasan eksplorasi

1. Setup monorepo menggunakan pnpm
2. Shell App sebagai host, remote apps: Profile & Dashboard
3. MF v1.5 mudah setup, cepat running
4. MF v2.0 memerlukan bootstrap init, DTS auto-generate, manifest handling → setup lebih panjang
5. UI di host harus menggunakan Suspense fallback agar tidak blank saat lazy-loading
6. Perbandingan: v1.5 → cepat & simpel, v2.0 → stabil, type-safe, cocok untuk proyek besar