Belajar Frontend - Micro-frontends & Module Federation

#Pendahuluan

Semua episode sebelumnya membangun TokoKita sebagai satu aplikasi. Episode 17 menjawab pertanyaan yang muncul saat organisasi membesar: bagaimana memecah frontend raksasa agar banyak tim bisa bekerja dan deploy secara independen? Jawabannya — micro-frontends — adalah salah satu tren arsitektur yang paling matang di 2026.

Penting: micro-frontends bukan teknologi wajib, melainkan keputusan organisasional dengan harga yang nyata. Memahami kapan ia layak — dan kapan monolith justru lebih baik — adalah tanda kedewasaan engineer. Episode ini membahas keduanya.

#Masalah Frontend Monolitik

Saat satu kodebase frontend dilayani banyak tim:

Dampaknya: satu fitur kecil di tim Promo memaksa seluruh tim menunggu satu pipeline deploy, satu build raksasa, dan konflik codebase yang terus-menerus. Micro-frontends memecah hal ini per-tim.

#Apa Itu Micro-frontends

Micro-frontend membagi frontend menjadi beberapa aplikasi kecil yang dimiliki dan di-deploy tim berbeda, lalu dirangkai menjadi satu pengalaman:

Yang paling penting: pengguna tidak boleh tahu bahwa halaman sebenarnya terdiri dari beberapa aplikasi.

#Pola Integrasi

Ada tiga pendekatan merangkai:

1. Build-time composition — semua aplikasi digabung saat build. Sederhana, tetapi kembali membuat satu deploy bersama.
2. Runtime integration — tiap bagian di-fetch dan dirangkai di browser saat runtime. Ini inti Module Federation.
3. Server-side composition — server merangkai HTML dari tiap bagian (mis. Edge — episode 20).

#Module Federation

Module Federation (dari Webpack, kini didukung Vite/RSBuild) memungkinkan satu aplikasi memuat kode aplikasi lain pada runtime — seperti import biasa, tetapi lintas aplikasi:

import { federation } from "@module-federation/vite";
 
export default defineConfig({
  plugins: [
    federation({
      name: "host",
      remotes: {
        cart: "http://localhost:5002/assets/remoteEntry.js",
      },
    }),
  ],
});

import { CartApp } from "cart/CartApp";
 
export function Page() {
  return (
    <main>
      <h1>Katalog</h1>
      <CartApp /> {/* dimuat dari remote di runtime */}
    </main>
  );
}

remoteEntry.js bertindak sebagai "menu runtime" yang bisa diperbarui tanpa men-deploy ulang host — inilah kunci independensi tim.

#Trade-off yang Jujur

Micro-frontends tidak gratis. Sebelum memilih, hitung harga ini:

Kapan pakai: organisasi sudah puluhan tim, alur deploy satu monolith benar-benar menjadi bottleneck, dan tim punya kapasitas mengelola infrastruktur tambahan.

Kapan jangan: tim kecil/medium, satu aplikasi yang masih bisa dirawat — di sana micro-frontends hanya menambah biaya tanpa manfaat. Seperti kata pepatah arsitektur: solve the problem you actually have.

#Praktik: Pemecahan Hipotetis TokoKita

Simulasi arsitektur jika TokoKita membesar:

toko-kita-host/     → shell: navigasi, routing, layout (Next.js)
app-catalog/        → katalog & pencarian produk (Vite + React)
app-cart/           → keranjang & checkout (Vite + React)
app-account/        → profil & pesanan (Next.js)

Aturan yang harus dijaga: shell memegang navigasi & shared design system (episode 25), tiap app mandiri, dan kontrak antar-app adalah data (props/URL/state) — bukan import internal yang sembarangan.

#Common Pitfalls

#Penutup

Inti yang harus dibawa pulang:

• Micro-frontends memecah frontend monolitik per tim — deploy independen, pengalaman tetap satu.
• Integrasi runtime lewat Module Federation memungkinkan update per-bagian tanpa redeploy host.
• Trade-off nyata: kompleksitas vs skalabilitas; gunakan hanya saat monolith benar-benar bottleneck.
• Shell + domain apps + shared design system adalah struktur yang sehat.

Di episode 18 selanjutnya kita mengamankan aplikasi: web security dasar — XSS, CSRF, CORS, CSP, dan HTTPS, untuk melindungi TokoKita dan penggunanya dari serangan yang paling umum. Sampai jumpa di episode 18!