Cara Kerja Microfrontend: Arsitektur, Pola, dan Contoh

Beranda » Ular sanca » Cara Kerja Microfrontend: Arsitektur, Pola, dan Contoh

Microfrontend telah menjadi salah satu pola arsitektur frontend yang paling banyak dibicarakan untuk tim yang sudah tidak lagi menggunakan monolit satu halaman klasik. Ketika puluhan pengembang bekerja sama di basis kode yang sama, siklus rilis melambat, regresi muncul di mana-mana, dan perubahan UI kecil tiba-tiba membutuhkan koordinasi yang masif. Microfrontend mengatasi masalah tersebut dengan membagi UI menjadi beberapa bagian yang dibangun dan diterapkan secara independen.

Dalam panduan ini kita akan membahas apa itu microfrontend, mengapa mereka muncul, dan bagaimana mereka berhubungan dengan layanan mikro., ide inti apa yang harus Anda hormati saat merancangnya, dan bagaimana cara kerjanya dalam praktik dengan teknologi seperti React, Angular, Next.js, Komponen Web, Federasi Modul Webpack, dan Single‑SPA. Kami juga akan mendalami pola arsitektur nyata, praktik terbaik, kesalahan umum, dan contoh konkret seperti katalog produk dan keranjang belanja yang diimplementasikan sebagai microfrontend terpisah.

Apa itu microfrontend dan mengapa itu muncul?

Istilah “micro frontends” dipopulerkan sekitar tahun 2016 di ThoughtWorks Technology Radar sebagai jawaban atas tren yang sangat konkret: arsitektur backend beralih ke layanan mikro, tetapi sisi peramban tetap menjadi monolit besar dan rapuh yang dimiliki oleh satu tim. Seiring waktu, SPA "klien gemuk" tersebut menjadi sulit dikembangkan, meskipun backend terbagi dengan baik menjadi layanan-layanan kecil.

Microfrontend pada dasarnya adalah ide layanan mikro yang diterapkan pada UI browserAlih-alih satu repositori frontend yang besar, Anda menyusun antarmuka pengguna dari beberapa aplikasi yang lebih kecil dan mandiri. Masing-masing aplikasi memiliki domain bisnis yang jelas (misalnya, "checkout", "pencarian produk", "profil mahasiswa") dan dapat dibangun, diuji, dan diterapkan secara individual.

Sama seperti layanan mikro yang membagi logika backend menjadi beberapa unit yang dapat disebarkan, mikrofrontend membagi frontend menjadi beberapa bagian vertikal yang menjangkau dari basis data atau API, melalui backend, hingga antarmuka pengguna. Tim lintas fungsi memiliki irisan vertikal tersebut secara menyeluruh, dari skema data hingga komponen UI.

“Organisasi vertikal” ini berbeda dengan pemisahan horizontal berdasarkan lapisan (satu tim untuk UI, satu lagi untuk API, satu lagi untuk basis data). Tim vertikal cenderung mengirimkan produk lebih cepat karena mereka tidak perlu mengoordinasikan setiap perubahan kecil di separuh perusahaan.

Dari sudut pandang aplikasi, microfrontend adalah aplikasi web otonom yang dapat disusun menjadi pengalaman yang lebih besar: dapat memiliki peruteannya sendiri, manajemen status, sistem desain, dan jalur penyebarannya sendiri, selama mematuhi serangkaian kontrak dengan sistem lainnya (URL, acara, API, pustaka bersama, dll.).

Ide dan prinsip inti di balik microfrontends

Beberapa prinsip berulang muncul dalam arsitektur mikrofrontend yang sukses; aturan-aturan tersebut tidak ketat, tetapi akan menyelamatkan Anda dari banyak rasa sakit jika Anda menggunakannya sebagai pagar pembatas.

Agnostisisme teknologi Ini adalah salah satu prinsip paling terkenal: setiap tim harus dapat memilih dan meningkatkan tumpukan teknologinya tanpa harus melakukan sinkronisasi dengan tim lain. Mungkin satu microfrontend menggunakan React, satu lagi menggunakan Angular, dan satu lagi menggunakan Vue. Abstraksi asli browser seperti Elemen Kustom (Komponen Web) membantu menyembunyikan perbedaan tersebut di balik API DOM standar.

Isolasi yang kuat antara basis kode tim adalah tujuan utama lainnyaIdealnya, microfrontend tidak berbagi runtime JavaScript atau variabel global. Setiap bundel bersifat mandiri, memuat dependensinya sendiri, dan tidak bergantung pada status tersembunyi dari yang lain. Hal ini mengurangi penggabungan yang tidak disengaja dan membuat penerapan independen jauh lebih realistis.

Untuk menghindari konflik penamaan, tim sering menyetujui namespace yang eksplisit untuk kelas CSS, acara DOM, kunci localStorage, cookie, atau bahkan nama tag Elemen Kustom. Misalnya, tim checkout mungkin mengawali sesuatu dengan chk- atau gunakan tag seperti <blue-buy>, sementara tim rekomendasi menggunakan rec- or <green-recos>Sekilas, DOM memberi tahu Anda siapa pemilik bagian yang mana.

Prinsip lainnya adalah lebih memilih kemampuan browser asli daripada API global khusus. Daripada menciptakan sistem PubSub serba guna, Anda dapat mengandalkan peristiwa DOM standar, CustomEvent, API riwayat untuk perutean atau DOM itu sendiri sebagai lapisan integrasi. Kapan pun Anda benar-benar membutuhkan API bersama, buatlah sekecil dan sestabil mungkin.

Terakhir, ketahanan harus menjadi bagian dari desain sejak hari pertamaSetiap mikrofrontend tetap harus memberikan nilai tertentu ketika JavaScript lambat, gagal, atau terblokir. Teknik seperti rendering sisi server, peningkatan progresif, dan layar kerangka membantu menjaga kinerja yang dirasakan tetap tinggi bahkan dalam kondisi jaringan yang buruk.

Apa yang dimaksud dengan “aplikasi web modern” dalam konteks ini?

Tidak semua situs web membutuhkan microfrontends atau strategi integrasi browser yang rumitModel mental yang baik berasal dari "kontinum dokumen-ke-aplikasi": di sebelah kiri, sebagian besar dokumen statis saling terhubung; di sebelah kanan, terdapat aplikasi yang sepenuhnya interaktif seperti editor foto daring.

Jika proyek Anda lebih dekat dengan dokumen statis, komposisi server-render sederhana seringkali cukupServer mengumpulkan fragmen HTML dari berbagai sumber, menggabungkannya, dan mengirimkannya ke peramban. Pembaruan terjadi melalui pemuatan halaman penuh atau injeksi Ajax kecil, dan itu tidak masalah.

Saat Anda beralih ke pengalaman yang lebih dinamis seperti aplikasi—umpan balik instan, bekerja offline, pembaruan UI yang optimis—integrasi sisi server saja tidak lagi memadai. Anda membutuhkan komposisi sisi klien, manajemen status, dan perutean. Di sinilah microfrontend menjadi menarik: mereka memberi Anda cara untuk menskalakan kompleksitas tersebut di banyak tim.

Organisasi vertikal dan irisan berbasis domain

Rekomendasi umum adalah menyelaraskan microfrontend dengan domain bisnis, bukan lapisan teknis.Pikirkan dalam konteks perjalanan pengguna: "keranjang belanja", "detail produk", "pengguna admin", "jadwal kursus", "data siswa", "faktur", dll.

Masing-masing domain ini dapat menjadi microfrontend-nya sendiri dengan tanggung jawab yang ditentukan dengan jelasDalam sistem universitas, satu aplikasi dapat mengelola profil mahasiswa, yang lain mengelola profil staf, yang ketiga mengelola jadwal kuliah, dan yang ketiga mengelola UI hasil ujian. Mereka berbagi shell dan mungkin beberapa gaya, tetapi masing-masing merupakan aplikasi independen dari perspektif penerapan.

Pengirisan yang baik juga mempertimbangkan konteks terbatas dari layanan mikro backend AndaIdealnya, mikrofrontend untuk "penagihan" terutama terhubung dengan layanan mikro penagihan, sedangkan frontend "katalog" terhubung dengan layanan katalog, dan seterusnya. Hal ini menjaga kohesi setiap irisan vertikal dan mengurangi ketergantungan antar-tim.

Integrasi teknis: DOM sebagai API dan Komponen Web

Dalam arsitektur mikrofrontend sisi browser, DOM sendiri sering bertindak sebagai API integrasi utamaAlih-alih memanggil JavaScript satu sama lain secara langsung, tim mengekspos fungsionalitas melalui elemen, atribut, dan peristiwa HTML.

Elemen Kustom (bagian dari Komponen Web) adalah primitif yang kuat untuk iniSebuah tim dapat membangun fitur menggunakan kerangka kerja apa pun yang diinginkannya dan kemudian membungkusnya sebagai tag khusus, misalnya <order-minicart></order-minicart>Kontrak publik komponen tersebut ditentukan oleh nama tag, atribut, dan peristiwa yang dipancarkannya, bukan oleh implementasi internalnya.

Dukungan browser untuk Elemen Kustom v1 sekarang solid di semua browser utama, yang berarti Anda jarang membutuhkan polyfill. Kebanyakan framework utama – React, Vue, Angular, Svelte, Preact – dapat merender atau menyematkan elemen kustom seolah-olah merupakan tag HTML biasa, dan banyak di antaranya juga dapat dikompilasi menjadi elemen kustom itu sendiri.

Pola integrasinya terlihat seperti ini: microfrontend “halaman produk” menentukan fitur apa saja yang akan muncul di halaman (pemilih, tombol beli, mini-cart, rekomendasi). Ini menyuntikkan elemen khusus seperti <blue-buy sku="t_porsche"></blue-buy> or <green-recos sku="t_porsche"></green-recos>Tim yang memiliki fitur tersebut mendaftarkan elemen mereka dengan customElements.define dan menerapkan panggilan balik siklus hidup seperti connectedCallback or attributeChangedCallback.

Ketika varian produk berubah, halaman dapat membuat ulang elemen tersebut atau hanya memperbarui atributnyaJika komponen memenuhi atribut yang relevan, komponen tersebut dapat merender ulang dirinya sendiri. Secara internal, komponen dapat menggunakan string templat, React, Vue, atau mesin render apa pun; integrator tidak perlu mempedulikannya.

Komunikasi sisi klien: peristiwa dan hubungan DOM

Melewati atribut berfungsi dengan baik untuk skenario “data masuk” satu arah, tetapi banyak interaksi nyata membutuhkan komponen untuk berkomunikasi kembali dengan lingkungannya atau dengan saudaranya. Contoh tipikal adalah tombol "beli" yang harus memberi tahu keranjang belanja mini ketika suatu barang ditambahkan.

Daripada membangun bus acara global khusus, Anda dapat mengandalkan acara browserPengiriman komponen CustomEvent contoh yang muncul melalui pohon DOM. Elemen induk atau bahkan window dapat mendengarkan kejadian tersebut dan mengatur tanggapan.

Misalnya, tombol beli mungkin memancarkan peristiwa seperti blue:basket:changed dengan muatan keranjang saat ini. Mini-cart berlangganan acara tersebut pada window atau pada elemen kontainer bersama dan menyegarkan status internalnya setiap kali diaktifkan.

Pendekatan ini menjaga komponen tetap independen: Tombol beli tidak tahu siapa, jika ada, yang mendengarkan peristiwanya. Tombol tersebut hanya memenuhi kontraknya. Dan mini-cart hanya bergantung pada semantik peristiwa, bukan pada detail implementasi fragmen lainnya.

Rendering sisi server dan komponen universal

Jika Anda peduli dengan kinerja first-paint, SEO, atau ketahanan saat JavaScript gagal, server-side rendering (SSR) sangatlah pentingKomponen Web sisi klien murni hanya muncul setelah bundel JS diunduh dan dijalankan, yang mungkin mengakibatkan layar putih pada jaringan yang lambat.

Solusi pragmatis adalah menggabungkan Elemen Kustom dengan server-side include (SSI/ESI)Setiap mikrofrontend mengekspos titik akhir HTTP yang mengembalikan HTML untuk fragmennya, misalnya /blue-buy?sku=t_porscheHalaman utama, yang ditampilkan oleh shell atau aplikasi host, menyertakan placeholder seperti <!--#include virtual="/blue-buy?sku=t_porsche" --> yang diperluas oleh server web (seringkali nginx) sebelum mengirim respons ke browser.

Saat runtime di browser, elemen kustom yang sama dihidrasi atau diinisialisasi ulang Setelah bundel JS-nya dimuat, Anda akan mendapatkan komponen "universal": komponen ini dapat dirender di server untuk kecepatan dan SEO, lalu berperilaku seperti elemen kustom yang sepenuhnya interaktif di klien.

Salah satu kelemahan SSR dengan penyertaan adalah bahwa fragmen paling lambat menentukan total waktu responsCaching di tingkat fragmen hampir wajib. Untuk bagian yang mahal dan sangat personal (seperti rekomendasi), Anda dapat melewati proses rendering sisi server dan memuatnya secara asinkron di klien.

Layar kerangka adalah kompromi yang baik untuk menghindari pergeseran tata letak yang mengagetkanSebuah fragmen dapat di-server-render sebagai placeholder berwarna abu-abu dengan ukuran yang kurang lebih sama dengan konten akhir. Ketika data asli tiba di sisi klien, kerangkanya akan ditukar tanpa reflow yang besar.

Pemuatan data dan kinerja yang dirasakan

Di dunia microfrontend, Anda harus berpikir hati-hati tentang di mana dan kapan data diambilAnda dapat mengambil semua data dari sisi server, semua data dari sisi klien, atau menggunakan hibrida. Setiap pilihan memengaruhi strategi caching, waktu interaktif, dan kecepatan yang dirasakan.

Sisi server secara alami mendorong pengambilan sisi server per fragmenSetiap mikrofrontend berkomunikasi dengan layanan backend "nya", merender HTML, dan mengembalikannya ke shell. HTML tersebut dapat di-cache secara independen dari fragmen lain, yang membantu menskalakan bagian dengan lalu lintas tinggi seperti login atau daftar produk.

Saat memuat data pada klien, Anda harus menganggarkan untuk status progresif: kerangka awal, pembaruan cepat saat atribut berubah, dan perilaku fallback saat API lambat. Terkadang, menyimpan data lama hingga data baru tiba lebih nyaman secara visual daripada menampilkan kerangka untuk setiap perubahan kecil.

Microfrontends dengan React

React adalah pilihan yang sangat populer untuk mengimplementasikan microfrontend karena ekosistem dan optimasi renderingnyaDOM virtual dan diffing memudahkan pembaruan bagian-bagian kecil UI berdasarkan perubahan properti atau status global, dan Anda dapat menggabungkan aplikasi React sebagai SPA mandiri atau sebagai Elemen Kustom.

Migrasi antar versi React cenderung bertahap dan relatif mudah Dibandingkan dengan beberapa kerangka kerja lain, hal ini berguna ketika banyak tim independen mengelola microfrontend yang terpisah. Anda tidak perlu semua fragmen berpindah dari satu versi utama ke versi lainnya secara bersamaan.

Sisi sebaliknya adalah bahwa mikrofrontend React yang terdesentralisasi dapat menyebabkan penyebaran sumber daya: banyak tim, banyak pipeline CI/CD, banyak bundel, banyak repositori kecil. Tanpa otomatisasi yang memadai untuk proses build, provisioning, dan observabilitas, beban kerja tersebut menjadi sulit dikelola.

Masalah praktis lainnya adalah ukuran bundelJika setiap microfrontend mengirimkan salinan React dan pustaka bersama mereka sendiri, total ukuran unduhan dapat membengkak, terutama ketika beberapa fragmen diperlukan untuk merender halaman. Solusi seperti Federasi Modul (untuk berbagi dependensi saat runtime) atau tumpukan yang sangat selaras di seluruh tim dapat mengatasi hal ini.

Microfrontends dengan Angular

Angular cocok untuk pengaturan mikrofrontend yang lebih beropini, terutama saat Anda menggunakan monorepo dan perkakas di sekitarnya (seperti Nx). Ruang kerja Angular diatur ke dalam proyek dan pustaka, sehingga memudahkan untuk membagi solusi besar menjadi beberapa aplikasi dan pustaka bersama.

Sejak Angular 12 dan Webpack 5, Federasi Modul telah menjadi warga negara kelas satuProyek Angular dapat dikonfigurasi sebagai host atau remote menggunakan perintah skematik, menghubungkan yang diperlukan webpack.config.js dan logika bootstrap untuk Anda.

Dalam model ini, aplikasi Angular “host” bertindak sebagai shell yang mengatur navigasi, status bersama, dan berbagi dependensi. Mikrofrontend Angular individual (remote) mengekspos modul Angular yang dapat dimuat secara lambat oleh host secara dinamis melalui Federasi Modul.

Primitif perutean Angular yang biasa masih berlakuDi dalam microfrontend, Anda menggunakan RouterModule.forChild untuk definisi rute anak sehingga host adalah satu-satunya yang menggunakan forRootDengan cara ini, beberapa aplikasi Angular dapat hidup berdampingan dalam ruang URL terpadu tanpa konflik router.

Federasi Modul dalam praktik (contoh Angular)

Federasi Modul Webpack adalah fitur Webpack 5 yang memungkinkan beberapa build berbagi kode saat runtime. Satu build (host) secara dinamis memuat modul yang diekspos oleh build lain (remote) melalui file manifes kecil, biasanya bernama remoteEntry.js.

Di Angular Anda dapat melakukan ini dengan cukup cepatMisalnya, Anda dapat membuat aplikasi host (host-app) lalu jalankan skema seperti ng add @angular-architects/module-federation --project host-app --port 4200Ini menyiapkan konfigurasi ModuleFederationPlugin, file bootstrapping, dan logika runtime.

Anda kemudian membuat dua aplikasi Angular jarak jauh: satu untuk katalog produk dan satu untuk keranjang belanjaSetiap aplikasi mendapatkan port-nya sendiri (misalnya 4201 untuk products-app, 4202 untuk cart-app) dan konfigurasi Federasi Modulnya sendiri. Di webpack.config.js dari setiap remote yang Anda gunakan exposes untuk menerbitkan modul (biasanya modul aplikasi utama) di bawah kunci seperti ./ProductsModule or ./CartModule.

Shell host kemudian mendefinisikan rute yang memuat modul-modul jarak jauh tersebut secara malas melalui loadRemoteModule dari @angular-architects/module-federationMisalnya, menavigasi ke /products memicu impor dinamis dari http://localhost:4201/remoteEntry.js dan beban ProductsModule; /cart melakukan hal yang sama dengan remote kereta.

Di dalam mikrofrontend katalog Anda mungkin memiliki ProductsComponent yang menampilkan tabel item, membaca data dari PRODUCTS_CATALOG konstan dan menawarkan tombol “Tambahkan ke keranjang”. Saat diklik, item tersebut tetap ada di localStorage di bawah kunci “keranjang”, menambah jumlah ketika produk sudah ada.

Mikrofrontend keranjang kemudian membaca dari yang sama localStorage kunci, menampilkan tabel berisi nama produk, harga, jumlah, dan total, serta menyediakan tombol "Kosongkan keranjang" yang akan menghapus penyimpanan dan mengatur ulang status internalnya. Ini adalah cara sederhana namun ilustratif untuk berbagi status di antara dua aplikasi independen tanpa perlu terhubung erat.

Membangun shell host: tata letak, beranda, dan navigasi

Shell host yang solid sangat penting untuk pengalaman pengguna yang baik di seluruh microfrontendBiasanya memiliki tata letak global (header, footer, sidebar), perutean tingkat atas, dan terkadang status global seperti autentikasi atau tanda fitur.

Dalam contoh Angular, host mendefinisikan LayoutComponent yang membuat header dan bersarang router-outletHeadernya sendiri HeaderModule dan memaparkan tautan navigasi ke halaman beranda, daftar produk, dan keranjang melalui Angular routerLinkJalur rute dapat dipusatkan dalam enum seperti RoutesPath untuk menghindari tali sihir.

Modul perutean tata letak menyiapkan rute induk dengan LayoutComponent sebagai komponennya dan mendefinisikan rute anak untuk /home, /products dan /cart. itu /home jalur memuat lokal HomeModule; yang lainnya menggunakan loadRemoteModule untuk menarik mikrofrontend Angular pada waktu proses.

Di dalam host, sebuah SharedModule dapat mengumpulkan blok bangunan yang dapat digunakan kembali seperti header, layout, direktif umum, dan konstanta. Modul ini dapat diimpor ke direktori root. AppModule bersama dengan AppRoutingModule, yang mengarahkan jalur kosong ke konfigurasi perutean tata letak.

Next.js dan microfrontends

Next.js, sebagai kerangka kerja React tingkat produksi, juga berfungsi baik dengan pendekatan mikrofrontend, terutama karena mengadopsi Webpack 5 dan karenanya mendukung Federasi Modul. Fokusnya pada SSR, regenerasi statis inkremental, dan perutean menjadikannya kandidat yang baik untuk shell, mikrofrontend individual, atau keduanya.

Untuk mengimplementasikan microfrontends di Next.js Anda biasanya mengonfigurasi Federasi Modul di tingkat Webpack, mengekspos halaman atau komponen tertentu sebagai remote dan menggunakannya dari host. Meskipun Federasi Modul "hanya" merupakan fitur penggabungan JavaScript, Anda dapat menganggapnya sebagai pola arsitektur: fitur ini memungkinkan Anda memuat kode milik tim yang berbeda secara dinamis tanpa menggabungkan semuanya terlebih dahulu.

Untuk versi Next.js lama tanpa Webpack 5, Anda memerlukan adaptor eksternal untuk mengaktifkan dukungan federasi. Mulai Next 10.2 dan seterusnya, dukungan Webpack 5 sudah terintegrasi, yang sangat menyederhanakan pengaturan.

Single‑SPA dan kerangka kerja mikrofrontend lainnya

Single‑SPA adalah solusi terkenal lainnya untuk microfrontend, khususnya di ekosistem React. Fokusnya adalah mengorkestrasi beberapa aplikasi independen pada halaman yang sama, masing-masing terpasang ke dalam simpul DOM-nya sendiri berdasarkan rute saat ini.

Dengan Single‑SPA Anda dapat memiliki beberapa aplikasi React (atau bahkan menggabungkan React, Vue, Angular) yang hidup berdampinganKerangka kerja ini menangani kapan harus melakukan bootstrap, memasang, atau melepas setiap microfrontend saat pengguna bernavigasi, dan Anda menyambungkannya ke strategi perutean Anda (misalnya dengan React Router di setiap fragmen).

Saat memilih antara Single‑SPA dan Federasi ModulTim sering mempertimbangkan preferensi bundler/perkakas mereka. Federasi Modul terintegrasi secara mendalam dengan Webpack (dan, semakin meningkat, dengan alternatif seperti Rspack atau Rollup seiring dengan penambahan dukungan). Di sisi lain, Single-SPA lebih berfokus pada orkestrasi runtime daripada berbagi bundel, sehingga Anda dapat menggunakannya dengan berbagai alat build sambil menangani pembagian kode dengan cara lain.

Tujuan, fitur dan manfaat microfrontends

Tujuan utama dari microfrontends adalah untuk menskalakan pengembangan frontend di banyak tim tanpa mengalami kegagalan karena beban koordinasi.Alih-alih satu basis kode raksasa dengan rilis yang disinkronkan, Anda mendapatkan unit-unit kecil yang dapat di-deploy secara independen.

Tujuan utama biasanya meliputi: memungkinkan beberapa tim bekerja secara paralel, mendukung penerapan independen untuk berbagai bagian UI, menjaga fleksibilitas untuk menggunakan berbagai teknologi jika masuk akal, dan meningkatkan pemeliharaan dengan mengurangi ukuran dan kompleksitas setiap basis kode.

Karakteristik khas dari arsitektur semacam itu adalah penggunaan kembali komponen melalui pustaka bersama, integrasi modular melalui shell aplikasi, jalur independen per microfrontend, pengoptimalan kinerja melalui CDN dan caching, penanganan keamanan terpusat, dan observabilitas yang kuat.

Dari perspektif bisnis, manfaatnya sangat besar:pengembangan dapat ditingkatkan skalanya dengan lebih banyak tim, kegagalan dapat diisolasi dengan lebih baik, fitur dapat diluncurkan atau dibatalkan per domain, dan tumpukan frontend lama dapat dimigrasikan secara bertahap dengan mengganti satu bagian pada satu waktu daripada menulis ulang keseluruhan aplikasi.

Komponen utama dalam arsitektur microfrontend

Meskipun implementasinya bervariasi, sebagian besar arsitektur microfrontend memiliki beberapa komponen struktural yang sama yang menjaga semuanya tetap koheren.

Shell aplikasi (atau kontainer) adalah tulang punggungnyaIa memiliki tata letak eksternal, navigasi global, autentikasi, terkadang status global, dan logika untuk memuat atau membongkar mikrofrontend. Dalam pengaturan berbasis peramban, halaman inilah yang menarik semua bundel lainnya.

Setiap microfrontend adalah modul mandiri yang mengimplementasikan kemampuan tertentu, seperti katalog produk, keranjang belanja, profil pengguna, atau panel admin. Ini mengekspos permukaan integrasi (rute, Elemen Kustom, remote Federasi Modul) dan menyembunyikan detail internal dari sistem lainnya.

Bus acara atau sistem pesan sering hadir untuk komunikasi lintas mikrofrontendIni bisa berupa abstraksi sederhana atas peristiwa DOM, penyimpanan Redux terpusat, atau broker pesan kustom. Tujuannya adalah semantik publikasi/berlangganan yang terpisah: sebuah mikrofrontend memancarkan peristiwa tanpa mengetahui siapa yang menanganinya.

Pustaka bersama menampung komponen UI yang dapat digunakan kembali, utilitas, token desain, dan klien umumDalam pengaturan monorepo, alat seperti Nx sangat efektif, memungkinkan Anda menentukan paket bersama yang digunakan oleh banyak aplikasi dengan batasan yang ketat dan versi yang konsisten.

Kolektor dan perkakas observabilitas (misalnya menggunakan OpenTelemetry) menggabungkan log, metrik, dan jejak dari semua microfrontend, sehingga memungkinkan untuk mendiagnosis masalah yang mencakup beberapa fragmen atau layanan.

CDN melengkapi gambar di sisi pengiriman, menyimpan aset statis seperti bundel JS, CSS, dan gambar di dekat pengguna, mengurangi latensi, dan memindahkan beban ke server asal. Dalam pengaturan mikrofrontend, Anda sering kali menghosting setiap aset fragmen di jalur CDN-nya sendiri untuk penyimpanan dan peluncuran yang independen.

Arsitektur dan pola desain untuk microfrontend

Ada katalog pola yang kaya yang berlaku khusus untuk microfrontend, biasanya ditentukan oleh cara Anda menyusun, menyebarkan, dan menghubungkannya.

Komposisi berbasis komponen berarti membangun UI dari komponen web atau primitif serupaSetiap komponen memiliki tanggung jawab tunggal, masukan dan keluaran yang jelas, dan dapat diuji secara terpisah. Lapisan komposisi tingkat yang lebih tinggi (seperti shell atau kerangka orkestrasi) menyusun komponen-komponen tersebut ke dalam halaman penuh.

Pola federasi menekankan otonomi aplikasi yang lengkapSetiap mikrofrontend adalah aplikasi mandiri dengan siklus hidup dan timnya sendiri; shell atau gateway API hanya merutekan permintaan/data ke fragmen yang tepat. Komunikasi terjadi melalui REST API atau event yang terdefinisi dengan baik.

Pola shell aplikasi secara efektif adalah pendekatan “host”Shell memuat microfrontend, menangani masalah lintas sektor seperti navigasi dan keamanan, serta memastikan tampilan & nuansa yang konsisten. Hal ini sangat umum terjadi pada pengaturan berbasis Federasi Modul atau SPA Tunggal.

Pola gerbang API dan Backend‑for‑Frontend (BFF) berfokus pada sisi serverSebuah gateway API berada di depan banyak layanan backend, merutekan permintaan, dan menerapkan keamanan. BFF melangkah lebih jauh: setiap frontend (web, seluler, IoT) dapat memiliki backend khusus yang disesuaikan dengan kebutuhannya.

Pola penyimpanan data terdistribusi mengakui bahwa mikrofrontend yang berbeda mungkin mengelola sumber datanya sendiri atau cache. Di peramban, hal ini sering kali berarti menggunakan kunci localStorage, basis data IndexedDB, atau penyimpanan dalam memori yang terpisah, sementara di backend, hal ini berarti basis data terpisah per layanan mikro.

Observabilitas, penyebaran independen, skalabilitas horizontal, dan pola keamanan mengatasi masalah operasional: cara memantau setiap fragmen, cara menyebarkannya tanpa gangguan global, cara menskalakannya di bawah beban, dan cara menerapkan autentikasi/otorisasi secara konsisten.

Komposisi perutean dan pola pemuatan malas merupakan hal yang penting bagi UX dan kinerjaRouter utama menentukan mikrofrontend mana yang menangani jalur mana, dan setiap mikrofrontend memiliki router internalnya sendiri. Pemuatan lambat memastikan Anda hanya mengunduh kode untuk fragmen yang benar-benar diperlukan untuk rute saat ini.

Terakhir, pola komunikasi berbasis peristiwa memastikan bahwa mikrofrontend yang terhubung secara longgar masih dapat berkoordinasi melalui peristiwa domain, tanpa memperkenalkan ketergantungan langsung yang akan mengalahkan tujuan modularitas.

Kapan menggunakan microfrontend (dan kapan tidak)

Microfrontends bersinar dalam aplikasi yang besar dan kompleks dengan domain fungsional yang terdefinisi dengan baikBayangkan platform e-commerce, sistem manajemen perusahaan, portal kota, platform pendidikan, portal kesehatan besar, atau produk apa pun dengan banyak tim yang bekerja di area fungsional terpisah.

Mereka sangat berguna ketika Anda memiliki beberapa tim yang bekerja secara paralel yang membutuhkan otonomi dalam pilihan teknologi, siklus rilis, dan prioritas, atau ketika Anda sedang memodernisasi frontend lama secara perlahan dan tidak mampu melakukan penulisan ulang sepenuhnya. Anda dapat membagi satu area pada satu waktu ke dalam microfrontend baru dan mengintegrasikannya dengan shell lama.

Mereka juga membantu ketika bagian-bagian aplikasi yang berbeda perlu diskalakan secara berbedaHalaman login atau checkout mungkin mendapatkan lebih banyak lalu lintas daripada layar konfigurasi admin; penskalaan bagian-bagian tersebut secara independen dapat menghemat banyak biaya infrastruktur.

Namun, microfrontend bukanlah makan siang gratis. Mereka menambah kompleksitas arsitektur, membutuhkan koordinasi yang kuat dalam UX dan kontrak bersama, serta memperkenalkan mode kegagalan baru (misalnya, satu fragmen tidak dimuat). Untuk aplikasi kecil atau menengah dengan satu tim, monolit yang terstruktur dengan baik seringkali lebih sederhana dan lebih hemat biaya.

Tim juga harus waspada terhadap “anarki kerangka kerja”Meskipun secara teknis memungkinkan setiap microfrontend menggunakan tumpukan yang sama sekali berbeda, kombinasi kerangka kerja yang tidak terkontrol menyulitkan perekrutan, penggunaan peralatan, dan pembagian kode. Tingkat penyelarasan yang wajar (misalnya, "kami mengutamakan React, tetapi kami mengizinkan Angular untuk domain tertentu") biasanya lebih efektif dalam jangka panjang.

Microfrontend memperluas pola pikir layanan mikro ke browser, memberi tim cara untuk membagi frontend besar menjadi beberapa bagian otonom berorientasi domain yang dapat berevolusi, diterapkan, dan diskalakan secara independen namun tetap membentuk pengalaman pengguna yang kohesif saat digabungkan melalui shell aplikasi, pustaka bersama, Federasi Modul, Komponen Web, atau kerangka kerja orkestrasi seperti Single‑SPA.