Micro frontend adalah antarmuka pengguna yang terdiri dari aplikasi frontend yang dimiliki dan dapat di-deploy secara independen. Pendekatan ini secara resmi ditekankan oleh Thoughtworks di 2016, dan sebuah 2024 survei melaporkan bahwa 23.6% sekitar 30% dari responden telah menggunakan micro frontends dalam tahun sebelumnya, dibandingkan dengan 75.4% in 2022. State of Frontend data
You may be dealing with the problem already. Three product teams share one frontend repository and wait for the same release train, even when one team is changing checkout, another is updating profiles, and the third is adjusting marketing pages. A micro frontend architecture separates those product areas so teams can own, test, and release them independently while users still experience one application.
Perbedaan itu penting. Micro frontend bukanlah folder, komponen, atau paket yang lebih kecil. Tujuan utamanya adalah Independensi organisasi dan rilis, didukung oleh batasan teknis yang membuat kepemilikan eksplisit. Arsitektur dapat menghilangkan bottleneck koordinasi, tetapi juga memperkenalkan tanggung jawab integrasi waktu eksekusi, pengelolaan dependensi, pengujian, keamanan, dan kinerja.
Isi Kandungan
- Memahami Konsep Micro Frontend
- Bagaimana Arsitektur Micro Frontend Berfungsi
- Menggambarkan Pola-Pola Micro Frontend Utama
- Kelebihan, Kekurangan, dan Risiko Tersembunyi
- Praktik Pengujian, Pengembangan, dan Migrasi
- Menggunakan Micro Frontends di Capacitor dan Electron
- Kapan Memilih Micro Frontends
Mengerti Konsep Micro Frontend
Dari satu frontend ke beberapa aplikasi yang dimiliki
A traditional frontend often has one repository, one build, and one deployment boundary. Even if the code is divided into clean feature folders, the teams behind those folders may still depend on the same pipeline and release schedule. A small change in one area can trigger a full application build, shared regression testing, and coordination across every team.
Micro frontend membagi aplikasi browser sekitar kemampuan bisnis. Tim checkout memiliki kontrol checkout, tim profil memiliki pengaturan akun, dan tim pemasaran memiliki konten promosi. Setiap potongan dapat memiliki kodebasenya sendiri, proses pengiriman, dan ritme rilis, kemudian menjadi bagian dari pengalaman yang lebih besar melalui shell atau layer komposisi.
Martin Fowler mendefinisikan pola tersebut sebagai Stil istilah arsitektur di mana aplikasi frontend yang dapat diaktifkan secara independen digabungkan menjadi satu keseluruhan. dalam konsep dasarnya dalam panduan arsitektur micro frontends dasarFrasa 'dapat dijalankan secara independen' memiliki bobot yang lebih besar daripada 'aplikasi frontend.' Tanpa batasan pengiriman independen, Anda mungkin memiliki monolit modular daripada sistem frontend mikro.
Analogi toko yang terdiri dari beberapa bagian.
Pikirkan sebuah toko departemen. Satu tim mengelola depan toko, tim lain mengoperasikan kasir, dan tim lain mengurus pengembalian barang. Pengunjung melihat satu toko, tetapi setiap area memiliki proses, tanggung jawab, dan staf yang berbeda. Frontend mikro bekerja sama: browser menampilkan pengalaman produk yang sama, tetapi beberapa tim mengoperasikan area antarmuka yang berbeda di balik layar.
Frame umum biasanya dimiliki oleh aplikasi shell, termasuk konteks autentikasi, navigasi, dan keputusan jalur. Frontend mikro memiliki halaman atau kemampuan di dalam frame tersebut. Tim setuju tentang batasan antara mereka, tetapi tidak perlu berbagi setiap detail implementasi.
Terminologi ini terkait dengan ekstensi pemikiran mikroservis ke browser setelah Thoughtworks menyorotkannya dalam Radar Teknologi bulan November 2016. Fowler kemudian mendokumentasikan kemajuan dari Assess ke Trial dan kemudian Adopt, yang menjelaskan pola pergerakan dari teknik yang muncul menuju pilihan arsitektur yang lebih terestablis. Untuk tinjauan praktis yang lebih luas tentang pengembangan web yang skalabel oleh NerdifyNamun, hal ini membantu untuk membandingkan pola dengan pendekatan berdekatan seperti arsitektur plugin, yang dibahas dalam artikel ini Arsitektur Panduan Plugin.
Pelajaran penting adalah bahwa micro frontend bukanlah upgrade default untuk setiap interface. Mereka berarti ketika batasan tim dan batasan rilis menciptakan rasa sakit nyata. Biaya yang dibayarkan hanya bila independensi itu layak untuk mengelola lebih banyak kontrak, aset, mode gagal waktu eksekusi, dan alat operasional.
Bagaimana Arsitektur Micro Frontend Berfungsi
Shell dan fragmennya
Sistem yang berfungsi biasanya dimulai dengan shell aplikasijuga disebut sebagai kontainer atau pengatur. Shell menampilkan tata letak umum, menetapkan routing, menyediakan konteks autentikasi, dan menyediakan elemen interface bersama seperti navigasi atau peringatan. Ia juga menentukan micro frontend mana yang harus dimuat dan di mana fragmen itu harus dipasang.
Fragmen masing-masing adalah aplikasi yang dipelihara secara independen. Mereka mungkin hidup di repositori terpisah, menggunakan CI pipeline sendiri, menerbitkan versi sendiri, dan mengekspos bundle, fragmen, komponen web, atau modul remote. Shell menggabungkan bagian-bagian itu di browser, baik ketika halaman dimuat atau ketika rute memerlukan mereka.
A batasan tidak berguna kecuali tim dapat bergantung padanya. Shell dan setiap fragmen memerlukan kontrak eksplisit yang mencakup perilaku mount, kepemilikan jalur, status muatan, penanganan kesalahan, token desain, harapan aksesibilitas, dan versi dependensi yang didukung.
Aturan praktis: Bagikan kontrak dan primitif visual dengan sengaja. Jangan bagikan detail implementasi runtime hanya karena dua tim saat ini menggunakan framework yang sama.
Komunikasi tanpa mereproduksi monolit
Fragmen kadang-kadang perlu berkomunikasi. Slicing checkout mungkin perlu tahu bahwa pengguna telah masuk, sementara slicing profil mungkin perlu menerbitkan event akun diperbarui. Tim dapat menggunakan acara browser khusus, toko bersama, parameter URL, atau layanan yang diinjeksikan.
Setiap pilihan menciptakan profil koneksi yang berbeda:
- Acara khusus tetapkan kepemilikan terpisah, tetapi tim harus mendokumentasikan nama acara, bentuk muatan, dan waktu.
- Toko bersama sederhanakan koordinasi status, tetapi mereka dapat mereproduksi grafik dependensi sentral yang arsitektur itu dimaksudkan untuk mengurangi.
- Parameter URL berfungsi baik untuk navigasi dan status yang dapat dibagikan, meskipun mereka tidak cocok untuk setiap interaksi.
- Jasa yang diinjeksikan Menghadirkan kemampuan yang dikendalikan, tetapi shell harus mempertahankan kontrak layanan tersebut.
Shell harus mengkoordinasikan apa yang dimiliki oleh aplikasi secara keseluruhan. Jika menjadi tanggung jawabnya untuk setiap fragmen dan aturan bisnis, maka telah menjadi monolit yang terdistribusi dengan proses pengiriman yang lebih rumit.
Progresi sejarah yang dokumentasi oleh Fowler menjelaskan mengapa pola ini sering dibandingkan dengan microservices. Kedua pendekatan memisahkan kepemilikan dan pengiriman, tetapi micro frontends menerapkan independensi tersebut pada interface browser. Dalam tooling saat ini, Penggunaan Federasi Modul Sekarang, single-spa tetap menjadi pilihan untuk tim yang ingin mendaftarkan aplikasi berdasarkan siklus hidup.
For example, the checkout team might release a payment-flow correction without rebuilding the catalog fragment. The catalog team can continue on a slower release cadence because the shell loads each approved slice according to its runtime configuration. That independent delivery boundary, not the visual appearance of separate components, is the architecture’s main payoff.
Sebuah tim yang mengevaluasi platform lingkungan juga perlu mempertimbangkan infrastruktur aplikasi untuk sistem frontendKarena repositori dan kerangka kerja sendiri tidak akan menyediakan komposisi yang dapat diandalkan.
Menggambarkan Pola Dasar Micro Frontend
Inti tidak ada mekanisme integrasi tunggal yang dapat menyelesaikan semua masalah frontend mikro. Pilih dengan membandingkan isolasi, komunikasi, pengiriman dependensi, perilaku browser, dan kepemilikan operasional daripada memilih alat yang paling modis.
| Polanya | Isolasi | Model Integrasi | Dependensi Bersama | Kinerja | Terbaik |
|---|---|---|---|---|---|
| Iframe | Proses dan Dokumen yang Kuat | Dokumen Terintegrasi dengan Komunikasi Antar Frame | Tidak Ada secara Default | Dapat Menambahkan Beban Pengisian dan Komunikasi | Ekspresi tidak terpercaya, legacy, atau sangat terisolasi |
| Komponen web | Elemen yang dienkapsulasi dan, jika digunakan, gaya Shadow DOM | Elemen kustom yang dimount oleh shell | Token desain yang dibagikan dan API browser | Seringkali dapat diprediksi, tetapi tergantung pada berat komponen | Tim yang membutuhkan fleksibilitas kerangka berdasarkan standar |
| Federasi Modul | Isolasi waktu eksekusi moderat | Modul remote yang dimuat dan dimount pada waktu eksekusi | Ketergantungan yang diatur secara eksplisit atau dibundel | Effisien ketika pengisian dan deduplikasi dikontrol | Aplikasi yang terintegrasi secara erat dengan rilis independen |
| single-spa | Pemisahan batasan orkestrasi daripada model isolasi lengkap | Aplikasi yang terdaftar melalui hook siklus hidup | Terletak pada aplikasi dan konfigurasi root | Terletak pada aturan muatan dan komposisi framework | Orkestrasi multi-framework dengan aktivasi berdasarkan rute |
Iframes
Sebuah iframe memberikan batasan yang paling kuat dalam perbandingan ini. Aplikasi yang diintegrasikan memiliki dokumen, gaya, dan lingkungan JavaScript sendiri, sehingga tidak akan mengubah DOM halaman induk secara tidak sengaja. Komunikasi melalui pesan antar-jendela dapat membuat jalur komunikasi yang dikendalikan.
Isolasi tersebut membuat iframes berguna untuk sistem legacy, pengalaman mitra, atau konten yang harus tetap terpisah. Biaya tampak dalam tata letak responsif, navigasi, aksesibilitas, pengelolaan fokus, dan autentikasi bersama. Sebuah iframe pembayaran dapat terasa seperti permukaan asing jika aplikasi induk dan aplikasi yang diintegrasikan tidak mengkoordinasikan dengan hati-hati.
Komponen web
Komponen web menggunakan standar browser daripada memerlukan setiap tim untuk menerima framework yang sama. Elemen kustom mendefinisikan permukaan pemasangan stabil, dan DOM Bayangan dapat membatasi kebocoran gaya. Shell masih perlu menangani routing aplikasi, status muatan, batasan kesalahan, dan token desain bersama.
Pilihan ini berfungsi dengan baik ketika tim ingin fleksibilitas framework tanpa membuat browser memuat runtime aplikasi seluruhnya untuk setiap potongan. Namun, ini tidak secara otomatis menyelesaikan ukuran dependensi, komunikasi keadaan, atau pengelolaan.
Federasi Modul
Module Federation, yang diperkenalkan dengan Webpack 5 dan didukung oleh tools seperti Vite dan Rspack, memuat modul yang dikompilasi dari entri jarak jauh pada waktu runtime. Ini menawarkan integrasi yang erat, sehingga komponen yang dibagikan dan navigasi yang disinkronisasi terasa lebih alami daripada yang seringkali terjadi dengan iframes.
Kenyamanan ini menciptakan tanggung jawab. Tim perlu interface yang kompatibel, aturan untuk dependensi yang dibagikan, penanganan versi remote, dan rencana pemulihan ketika remote tidak dapat dimuat. Perbedaan antara arsitektur monolitik dan mikro layanan memberikan konteks yang berguna untuk memisahkan independensi pengiriman dari dekomposisi sederhana code.
single-spa
single-spa berfungsi sebagai orchestrator yang tidak memihak framework. Tim mendaftarkan aplikasi dan hook siklus hidup, kemudian konfigurasi root mengaktifkannya sesuai dengan rute atau kondisi lainnya. Ini dapat mengkoordinasikan aplikasi yang dibangun dengan framework yang berbeda, tetapi tidak menghilangkan kebutuhan untuk kontrak, kebijakan dependensi, anggaran kinerja, atau kontrol keamanan.
Tim dapat menggabungkan mekanisme-mekanisme ini. Misalnya, root single-spa mungkin mengkoordinasikan rute, Module Federation mungkin menyediakan modul jarak jauh, dan komponen web mungkin mendefinisikan permukaan pemasangan publik. Gabungan ini dapat sangat kuat, tetapi setiap lapisan tambahan meningkatkan jumlah perilaku yang pengembang harus memahami dan menguji.
Manfaat, Tukar Menukar, dan Risiko Tersembunyi
Micro frontends move decisions across boundaries. They can reduce the blast radius of a release and give teams more control, but the system must then manage more artifacts, contracts, and runtime conditions.
| Manfaat | Benefit | Tambahan Biaya / Risiko Tersembunyi |
|---|---|---|
| Otonomi tim | Tim tim memiliki potongan bisnis dari awal hingga akhir | Tim harus menjaga aliran pipa yang terpisah, tanggung jawab on-call, dan disiplin perilisan |
| Deployment | Sebuah fragmen dapat dikirimkan tanpa harus membangun antarmuka lengkap kembali. | Rilis menjadi tidak atomik, sehingga versi yang tidak kompatibel dapat bertemu di produksi. |
| Isolasi gagal | A remote yang gagal dapat diisolasi dengan fallback | Batasan kesalahan yang buruk masih dapat membuat navigasi atau perjalanan kritis tidak dapat digunakan |
| Pengaturan | Pemuatan santai dan paket awal yang lebih kecil dapat membantu aliran umum | Banyak permintaan, kerangka kerja yang diulang code, dan inisialisasi jarak jauh dapat merusak kinerja waktu eksekusi |
| Pilihan Teknologi | Tim tim dapat menggunakan berbagai framework di mana batasan memungkinkannya | Tim dapat menggunakan kerangka kerja yang berbeda di mana batasan memungkinkan |
| Security | Sebuah batasan dapat membatasi berbagi implementasi langsung | Bungkus dapat menjalankan code remote yang belum cukup diverifikasi |
| Otoritas | Standar yang dibagi dapat melestarikan produk yang konsisten | Sistem desain, aturan ketergantungan, kontrak, dan dukungan platform memerlukan koordinasi yang terus-menerus |
Tagihan kinerja
Potongan independen biasanya menghasilkan aset yang dibangun secara terpisah. Tanpa aturan muatan yang hati-hati, browser mungkin meminta file tambahan, menginisialisasi code, atau mengunduh dependensi framework duplikat. Panduan kinerja untuk micro frontends menekankan muatan yang diperlukan, berbagi dependensi yang hati-hati, caching modul, dan isolasi gagal.
Desain yang praktis dimulai dengan basis untuk aplikasi yang ada. Ukur startup jalur, komposisi bundle, muatan remote, inisialisasi, dan gagal yang terlihat oleh pengguna. Kemudian tetapkan anggaran untuk shell dan setiap potongan yang berlalu lintas tinggi. Muatan yang paling lambat hanya membantu jika aplikasi tidak menghalangi perjalanan kritikal pada rantai panjang modul remote.
Keamanan di sambungan
Modul remote tidak otomatis aman karena memiliki repositori yang terpisah. Shell mungkin menjalankan code yang belum diverifikasi, dan batasan frontend tidak menggantikan otorisasi di API atau layanan token. Analisis micro frontend yang berfokus pada keamanan menyoroti mengapa kepercayaan, tanda tangan, periksa integritas, dan otorisasi memerlukan perhatian desain sebelum tim distribusi code waktu eksekusi.
Perbedaan versi menciptakan kelas risiko lainnya. Fragmen mungkin berfungsi sendiri tetapi gagal ketika bertemu dengan versi shell yang berbeda, library yang dibagikan, set token desain, atau payload acara. Panduan arsitektur Nx mengidentifikasi koordinasi, konfigurasi lingkungan, efisiensi aplikasi, dan kembali menggunakan sebagai tantangan yang berlanjut.
Arsitektur tidak menghapus koordinasi. Arsitektur mengubah koordinasi dari pertemuan rilis menjadi kontrak, otomatisasi, observabilitas, dan pengawasan.
Tim juga membutuhkan kepemilikan yang jelas untuk dependensi yang dibagikan, tinjauan aksesibilitas, tanggapan insiden, dan keputusan rollback. Jika tidak ada tim yang mengelola lapisan platform, setiap tim produk akan menyelesaikan komposisi secara berbeda, dan pengguna akan mengalami ketidaksesuaian yang dihasilkan sebagai satu aplikasi yang rusak.
Pengujian Pengembangan dan Praktik Pindah
Pengujian harus mencerminkan cara aplikasi berjalan. Fragment yang melewati ujian unit sendiri masih bisa gagal ketika shell menyediakan rute yang berubah, keadaan autentikasi yang tidak terduga, atau dependensi yang dibagikan yang berbeda.
Buat sistem ujian yang berlapis
Mulai dengan ujian terisolasi untuk setiap fragment. Ujian ini memvalidasi rendering, aturan bisnis, perilaku tombol, status muat, dan penanganan kesalahan lokal tanpa memerlukan shell yang lengkap.
Ujian kontrak berada di atasnya. Mereka memverifikasi antarmuka antara shell dan fragment, termasuk masukan untuk memasang, pola rute, event yang dikeluarkan, payload yang diharapkan, asumsi autentikasi, dan perilaku fallback. Ujian kontrak harus gagal sebelum produksi jika satu tim mengubah antarmuka yang dikonsumsi oleh tim lain.
Integrasi shell kemudian memuat artefak fragmen nyata dalam komposisi perwakilan. Mereka harus menutup routing, transisi autentikasi, navigasi bersama, gagal muat, dan kombinasi versi. Uji akhir ke akhir berada di atas karena mereka memvalidasi perjalanan lengkap seperti menjelajahi produk, masuk, dan menyelesaikan checkout di beberapa potongan yang diantar secara independen.
Kontrol permukaan rilis
Pakai manifest versi sehingga shell dapat mengidentifikasi artefak fragmen yang tepat yang dimuat. Manifest juga memberikan operator tempat untuk memasang versi yang baik ketika rilis jarak jauh menyebabkan kesalahan.
Kontrol yang berguna termasuk:
- Bendera fitur: Aktifkan fragmen baru untuk audiens internal atau rute tertentu sebelum paparan luas.
- Penyebaran canary: arahkan audiens terbatas ke artefak baru sambil memantau kesalahan browser, gagal muat, dan aksi bisnis kunci.
- Bundel yang dapat diamati: Tambahkan identifikasi rilis ke log, jejak, dan kesalahan klien sehingga tim yang bertanggung jawab dapat mengidentifikasi fragmen yang gagal.
- Rute rollback: Jaga artefak compatible sebelumnya tersedia dan buat reversion menjadi aksi operasional, bukan merekonstruksi manual.
Tim harus menguji shell dan fragmen bersama-sama dalam lingkungan yang mirip produksi. Sukses menjalankan lokal tidak membuktikan bahwa jalur pengiriman konten, cache, token autentikasi, atau manifest remote akan berperilaku dengan benar untuk pengguna. Praktik otomatisasi pengembangan dapat mendukung alur promosi dan rollback yang dapat diulang, tetapi arsitektur masih memerlukan kepemilikan yang jelas.
Migrasikan satu domain pada satu waktu
Migrasi strangler mengarahkan satu kemampuan dari monolit ke fragmen baru sementara bagian lainnya tetap tidak berubah. Toggle fitur dapat mendukung jalur parallel, memungkinkan tim membandingkan jalur baru dengan implementasi yang ada sebelum membuat jalur baru menjadi default.
Consider aplikasi perdagangan dengan tim katalog, akun, dan checkout yang terpisah. Shell memiliki navigasi dan autentikasi, tim katalog memiliki penggunaan produk, tim akun memiliki pengaturan profil, dan tim checkout memiliki alur keranjang dan pembayaran. Setiap tim menerbitkan artefaknya sendiri, sementara tes kontrak melindungi kesepakatan jalur dan event.
Mulai dengan domain yang berisiko rendah, publikasikan di balik flag, dan amati melalui perjalanan nyata. Perluas hanya setelah tim dapat mengembangkan, mendiagnosis, dan mengembalikan potongan tersebut tanpa meminta organisasi seluruhnya untuk mengkoordinasikan rilis.
Menggunakan Micro Frontends di Capacitor dan Electron
Aplikasi Capacitor atau Electron menambahkan lapisan lain di sekitar shell browser. Capacitor menempatkan web code di dalam WebView mobile native, sementara Electron menjalankan web code di dalam proses renderer desktop. Dalam kedua kasus, aplikasi dapat memuat shell lokal yang mengambil artefak frontend yang dipilih pada saat runtime daripada mengintegrasikan setiap perubahan interface ke dalam biner native.
Penataan tersebut menciptakan pemisahan rilis yang berguna. Kemampuan native, izin, dan bridge code tetap terkait dengan aplikasi yang diinstal, sementara permukaan yang dimiliki oleh web seperti akun, bantuan, katalog, atau pengaturan dapat mengikuti jalur pengiriman yang terpisah. Shell masih perlu memutuskan dari mana fragmen datang, versi mana yang disetujui, dan apa yang harus dilakukan oleh aplikasi jika langkah fetch atau verifikasi gagal.
Live updates dan rollback
Sistem live-update harus menganggap artefak frontend sebagai perangkat lunak yang dapat dirilis. Harus mengirimkan bundel yang ditandatanganidan memverifikasinya sebelum aktivasi, mendukung saluran rilis untuk peluncuran yang dipersiapkan, menerapkan update pada peluncuran berikutnya daripada mengganggu sesi aktif, dan menyediakan perlindungan rollback otomatis dengan reversion atomik.
Kontrol-kontrol tersebut dapat dipetakan secara alami ke pengiriman frontend mikro. Shell mobile atau desktop dapat memasang manifest, mengambil fragmen yang kompatibel, memverifikasinya, dan mengaktifkannya hanya ketika bundel lengkap tersedia. Jika peluncuran berikutnya mendeteksi gagal, pembarui dapat kembali ke keadaan yang baik sebelumnya daripada meninggalkan pengguna dengan interface yang sebagian diperbarui.
Capgo adalah salah satu pilihan untuk model pengiriman ini. Platform pembaruan hidupnya untuk aplikasi CapacitorJS dan Electron menerbitkan bundle web yang ditandatangani, mendukung saluran yang ditargetkan, menerapkan pembaruan pada peluncuran berikutnya, dan menyediakan log, riwayat versi, metrik adopsi dan kegagalan, perlindungan rollback, integrasi CI/CD, dan API. Bagaimana Capacitor menghubungkan web dan native code.
Apa yang berubah dalam shell native
Penyulung native memperkenalkan keterbatasan yang aplikasi browser-only mungkin tidak menghadapi:
- Connectivity: Fragment mungkin tidak tersedia ketika perangkat dalam keadaan offline, sehingga shell memerlukan artefak yang dicache atau fallback lokal.
- Kompatibilitas: Bundle web mungkin bergantung pada perilaku bridge native yang tidak didukung oleh binary yang terpasang.
- Keamanan: code remote harus diotentikkan, integritasnya diperiksa, dan diotorisasi untuk konteks aplikasi.
- Pemulihan: Perluan shell harus dapat menolak bundle yang tidak valid dan memulihkan versi yang berfungsi tanpa memerlukan distribusi penyimpanan segera.
- Keamanan Sesi: Mengupdate selama proses pembayaran atau aliran formulir dapat menciptakan keadaan tidak konsisten, sehingga aktivasi pada peluncuran berikutnya lebih aman daripada mengganggu pekerjaan aktif.
Model ini memperkuat rollback ketika platform pengiriman menawarkan aktivasi atomik dan metrik rilis yang rinci. Ini memperumit arsitektur ketika tim asumsikan bahwa independensi web menghilangkan perencanaan kompatibilitas native. Shell native tetap sebagai batas kontrak, dan setiap fragmen harus menghormatinya.
Kapan Memilih Micro Frontends
Pilih micro frontends ketika pengiriman independen adalah kebutuhan yang nyatabeberapa tim memiliki produk permukaan yang terpisah dengan jelas, atau antarmuka legacy dan baru harus berada bersama selama migrasi panjang. Diversitas teknologi juga dapat membenarkan pola ini ketika tim membutuhkan batasan framework yang tidak dapat diakomodasi oleh satu build dengan baik.
Hindari hal ini ketika tim kecil dapat dengan nyaman mengelola satu frontend, ketika domain memiliki keadaan mutable yang luas, atau ketika organisasi Anda tidak memiliki prosedur CI yang andal, observabilitas, pengujian kontrak, dan prosedur rollback yang dapat diandalkan. Interface yang terdistribusi tanpa dasar-dasar tersebut tidak menciptakan otonomi. Membuat lebih banyak tempat bagi kegagalan untuk disembunyikan.
Pakai tes awal yang sederhana:
- Pemilikan: Apakah satu tim dapat membuat keputusan untuk bagian yang disarankan?
- Batasan: Mengapa shell dan slice dapat berkomunikasi melalui kontrak yang stabil?
- Perlu rilis: Apakah tim memerlukan untuk mengeluarkan secara independen?
- Siap untuk operasional: Mengapa Anda dapat memantau, menguji, memasang, dan mengembalikan fragmen?
- Nilai pengguna: Apakah pemisahan ini akan meningkatkan pengiriman tanpa merusak kinerja atau konsistensi?
Mulai dengan area yang berisiko rendah seperti konten bantuan atau pengaturan. Tentukan kontrak pemasangan, kepemilikan rute, event, token desain, perilaku fallback, dan kebijakan versi. Kirimkan di balik flag fitur, ukur biaya bundle yang ditambahkan dan biaya penggunaan, dan dokumentasikan setiap saluran baru, manifest, aturan ketergantungan, dan jalur pengembalian.
Micro frontend adalah alat untuk independensi organisasi dan rilis, bukan peningkatan otomatis kualitas frontend. Jika masalah rilis kecil, monolit modular mungkin jawabannya yang lebih baik. Jika masalah koordinasi besar dan berkelanjutan, arsitektur micro frontend yang teratur dapat memberikan tim kebebasan yang mereka butuhkan.
Jika Anda mengevaluasi micro frontend untuk produk Capacitor atau Electron, Capgo dapat membantu Anda mengirimkan bundle web yang ditandatangani melalui saluran yang dikendalikan, mengaktifkan pembaruan pada peluncuran berikutnya, dan mengembalikan melalui perlindungan rollback. Kunjungi Capgo untuk meninjau opsi pengiriman, observabilitas, dan API sebelum Anda merancang proses rilis fragmen.
