Belajar Microfrontend - Sejarah, Latar Belakang & Mengapa Microfrontend

#Pendahuluan

Setelah di episode 0 kita menyiapkan environment — memastikan Node.js LTS, pnpm, Vite, dan tooling Module Federation siap — pada episode ini kita mundur sejenak dari hands-on dan memahami mengapa microfrontend lahir. Sejarah sebuah arsitektur mungkin terasa tidak penting, padahal justru di sanalah letak alasan mengapa desainnya seperti sekarang.

Mengapa harus memahami sejarah? Karena microfrontend tidak lahir dari ruang rapat arsitek semata, melainkan dari rasa sakit nyata para tim frontend yang terjebak di aplikasi monolitik yang kian membesar. Memahami asal-usulnya akan menjelaskan keputusan-keputusan desainnya — mengapa kita membangun host dan remote, mengapa kita menekankan independent deployability, dan mengapa kita tidak serta-merta merekomendasikannya untuk aplikasi kecil.

#Masalah Frontend Monolitik (SPA Besar)

Bayangkan satu aplikasi e-commerce dengan puluhan ribu baris kode, satu repo, dan satu bundle. Ini kondisi banyak organisasi besar. Masalahnya menumpuk:

#Satu Repo & Satu Bundle Besar

Semua kode — katalog, cart, checkout, profil — digabung dalam satu build. Build menjadi lambat, dan deployment terkunci semua tim dalam satu rilis. Satu perubahan kecil di bagian cart memaksa status checkout menunggu.

Satu bundle monolitik

bundle-aplikasi.js (
  catalog, product-detail, cart, checkout, account
) -> satu build -> satu deploy -> satu rilis

#Tim Tidak Bisa Rilis Independen

Karena semua tim bergantung pada satu bundle, siklus rilis ditentukan yang paling lambat. Tim yang sudah siap harus menunggu tim lain. Feedback loop memburuk — alih-alih rilis beberapa kali sehari, rilis jadi seminggu sekali atau lebih lama.

#Teknologi Terkunci

Begitu satu repo dibangun dengan React versi tertentu, hampir mustahil meng-upgrade sebagian. Kalau tim cart ingin mencoba Vue atau versi React yang lebih baru, seluruh aplikasi harus ikut. Inovasi teknologi terhambat oleh "least common denominator".

#Konflik Merge & Ownership Kabur

Dengan puluhan engineer di satu repo, konflik merge menjadi keseharian. Lebih parah, ownership jadi kabur — siapa yang bertanggung jawab atas kode katalog? Siapa yang mengubahnya terakhir? Ini menyulitkan review, on-call, dan accountability.

Warning

Bukan berarti monolit selalu salah. Masalah di atas muncul saat satu aplikasi dijaga oleh banyak tim besar. Untuk satu tim tunggal atau aplikasi kecil, monolit sering jadi pilihan yang tepat — kita bahas detail kapan tidak memakai microfrontend di episode 2.

#Dari Monolith ke Microfrontend

#Ide yang Dipinjam dari Microservices

Konsep memecah aplikasi besar menjadi unit-unit kecil sudah matang di sisi backend lewat microservices: pecah layanan ke domain (billing, cart, profile), satu tim satu domain. Microfrontend menerapkan prinsip yang sama di sisi frontend.

Prinsip yang dipinjam:

Prinsip Microservice	Terjemahan di Frontend
Independent deploy	Setiap remote bisa di-deploy tanpa menunggu yang lain
Team ownership	Satu tim pemilik penuh satu remote/domain
Integration runtime	Remote diintegrasikan saat load, bukan saat build
Teknologi per-servis	(Opsional) tiap remote boleh beda framework

#Konsep Inti: Independent Deploy + Team Ownership + Integrasi Runtime

Tiga kata kunci yang akan kita pakai terus:

Independent deploy — remote catalog bisa rilis sendiri tanpa men-deploy ulang shell.
Team ownership — satu tim memegang satu domain dari awal sampai akhir (juga di backend-nya, pola "full-stack feature team").
Integration runtime — remote bergabung ke halaman saat user browsing, bukan saat compile, jadi versi tiap remote independen.

#Kenapa Penting di 2026

Di 2026, beberapa faktor membuat microfrontend makin relevan:

Skala organisasi besar: e-commerce, perbankan, SaaS banyak yang punya tim frontend 50+ engineer. Satu monolit tidak bisa menampung itu.
Feedback loop rilis independen: dengan microfrontend, tiap tim bisa rilis hingga 10x sehari — bukan sekali seminggu.
Komposisi tim full-stack: tim pemilik domain mengontrol frontend + backend + infrastrukturnya, dan microfrontend memungkinkan kontrol penuh atas bagian frontendnya.
Module Federation 2.0 matang (stabil awal 2026) — tooling yang sebelumnya rumit kini jauh lebih mudah dan type-safe.

#Contoh Adopsi

Beberapa perusahaan besar menerapkan pola yang serupa:

Spotify — memecah UI besar menjadi banyak "potongan" kecil yang di-own tim, diintegrasikan di shell.
Zalando — pelopor pembagian frontend ke tim-tim domain (Project Mosaic); kami akan bahas pola Podium (server-side podlets) mereka di episode 22.
DAZN — streaming platform yang membagi customer journey (onboarding, player, billing) jadi unit independen.
Marriott — membagi booking flow besar menjadi aplikasi frontend yang dikelola tim berbeda.

Mereka tidak semua memakai Module Federation — ada yang memakai iframe, build-time, atau server-side composition — tetapi prinsip yang sama: memecah frontend besar agar tim bisa maju independen.

#Penutup

Pada episode 1 ini, kalian telah memahami latar belakang lahirnya microfrontend: masalah frontend monolitik, ide yang dipinjam dari microservices, pentingnya di 2026, dan contoh adopsi nyata.

Inti yang harus dibawa pulang:

SPA monolitik besar: build lambat, deploy terkunci, teknologi terkunci, konflik merge, ownership kabur.
Microfrontend meminjam prinsip microservices: independent deploy, team ownership, integration runtime.
Di 2026, skala tim 50+ engineer dan kebutuhan rilis 10x/hari menjadikannya relevan; Module Federation 2.0 membuat tooling jadi matang.
Contoh adopsi: Spotify, Zalando, DAZN, Marriott.

Di episode 2 selanjutnya, kita akan membedah konsep dasar dan arsitektur utama microfrontend — model lapisan host (shell), remotes, dan shared dependencies, strategi integrasi build-time vs run-time vs server-side, dua pendekatan utama 2026 (Module Federation 2.0 vs single-spa), serta trade-off dan kapan tidak perlu memakai microfrontend. Sampai jumpa di episode 2!