Micro Frontend #

Ketika orang pertama kali mendengar istilah microfrontend, fokusnya sering langsung ke teknologi: Webpack Module Federation, import maps, runtime loading, dan sebagainya.

Padahal di dunia nyata, microfrontend jauh lebih sering gagal atau berhasil karena faktor organisasi, bukan karena faktor teknis.

Artikel ini membahas microfrontend dari sudut pandang yang lebih jujur dan praktis:

Microfrontend sebagai cara membagi tim dan tanggung jawab, bukan sekadar memecah UI.

Microfrontend dan Conway’s Law #

Conway’s Law menyatakan:

Sistem yang dibangun akan mencerminkan struktur komunikasi organisasi yang membangunnya.

Artinya:

• Jika organisasi kamu terbagi per tim bisnis → UI akan ikut terbagi
• Jika organisasi kamu masih satu tim besar → UI akan cenderung monolithic

Microfrontend secara sadar memanfaatkan Conway’s Law, bukan melawannya.

Dari Monolithic Frontend ke Microfrontend #

Monolithic Frontend (Team-Centric Problem) #

+-----------------------+
|   Frontend Monolith   |
|-----------------------|
| - Shared Components   |
| - Shared State        |
| - Shared Release      |
+-----------------------+

1 repo
1 pipeline
1 jadwal release

Dampak ke tim:

• Semua perubahan harus koordinasi
• Release kecil ikut tertahan perubahan besar
• Ownership tidak jelas

Microfrontend (Team-Aligned Architecture) #

+-------------------- Browser --------------------+
|                                                 |
|  +-------------------------------------------+  |
|  |            Shell / Container App           |  |
|  |  (Routing, Layout, Auth, Observability)   |  |
|  +-------------------+-----------------------+  |
|                      |                          |
|   +------------------v--------------+           |
|   |   Microfrontend: Catalog        |           |
|   |   Owned by Team Catalog         |           |
|   +---------------------------------+           |
|                                                 |
|   +------------------v--------------+           |
|   |   Microfrontend: Checkout       |           |
|   |   Owned by Team Checkout        |           |
|   +---------------------------------+           |
|                                                 |
|   +------------------v--------------+           |
|   |   Microfrontend: Profile        |           |
|   |   Owned by Team Profile         |           |
|   +---------------------------------+           |
|                                                 |
+-------------------------------------------------+

Setiap microfrontend:

• Punya tim owner yang jelas
• Punya lifecycle sendiri
• Bisa berubah tanpa mengganggu tim lain

Prinsip Utama: Team per User Journey #

Microfrontend tidak dibagi berdasarkan komponen teknis, tapi berdasarkan alur nilai (user journey).

❌ Salah (Component / Layer Driven) #

• Header Team
• Button Team
• State Management Team

Ini hanya memindahkan masalah monolith ke repo berbeda.

✅ Benar (User Journey Driven) #

User Journey: Belanja

Browse → View Product → Add to Cart → Checkout → Payment

Mapping ke tim:

Team Catalog   → Browse & Discovery MF
Team Product   → Product Detail MF
Team Checkout  → Cart & Checkout MF
Team Payment   → Payment MF

Setiap tim:

• Bertanggung jawab dari UI sampai business logic
• Memiliki KPI yang langsung terkait journey

Model Tim yang Cocok: Team Topologies #

Microfrontend paling cocok dengan Stream-aligned team.

Stream-aligned Team #

• Fokus ke satu alur nilai bisnis
• Minim dependency ke tim lain
• Deliver value langsung ke user

Mapping ideal:

Stream-aligned Team
→ Microfrontend
→ Backend APIs
→ Metrics & Monitoring

Jika satu tim hanya mengurus “potongan UI kecil”, itu bukan microfrontend yang sehat.

Peran Platform Team dalam Microfrontend #

Microfrontend hampir selalu membutuhkan Platform / Enablement Team.

Platform Team Bertanggung Jawab Atas: #

• Shell application
• Routing global
• Authentication bootstrap
• Design system
• CI/CD template
• Observability (logging, tracing, error)

Yang tidak dilakukan platform team: #

• Mengembangkan fitur bisnis
• Mengontrol release tiap microfrontend

Bagan Struktur Tim Microfrontend #

+------------------- Platform Team -------------------+
| Shell App | Design System | CI/CD | Observability   |
+----------------------+------------------------------+

+-----------+      +-----------+      +-----------+
| Team A    |      | Team B    |      | Team C    |
| Catalog   |      | Checkout  |      | Profile   |
| MF A     |      | MF B      |      | MF C      |
+-----------+      +-----------+      +-----------+

Prinsip emas:

Platform enables, feature teams deliver.

Kenapa Banyak Implementasi Microfrontend Gagal? #

Bukan karena teknologi, tapi karena:

• Tim masih harus sinkron release
• Semua perubahan UI lewat satu approval
• Tidak ada ownership yang jelas
• Shell app berubah jadi “god object”

Jika struktur tim tidak berubah,

microfrontend hanya akan menjadi monolith yang lebih rumit.

Checklist: Apakah Organisasi Siap Microfrontend? #

Jawab ya untuk sebagian besar pertanyaan berikut:

• Satu tim bisa deploy tanpa koordinasi lintas tim
• Satu tim bertanggung jawab atas satu user journey penuh
• Ada platform team atau peran platform yang jelas
• Design system sudah stabil
• Observability terpusat

Jika belum: 👉 perbaiki struktur tim terlebih dahulu, bukan kodenya.

Penutup #

Microfrontend bukan sekadar teknik frontend modern. Ia adalah:

• Cara membagi tim
• Cara membagi tanggung jawab
• Cara mengurangi konflik koordinasi

Jika microfrontend kamu terasa rumit, kemungkinan besar masalahnya ada di organisasi, bukan di JavaScript.