Micro frontend adalah antarmuka pengguna yang terdiri dari aplikasi frontend independen dan dapat di-deploy. Pendekatan ini secara resmi ditekankan oleh Thoughtworks di 2016,dan sebuah 2024 menunjukkan bahwa 23.6% responden telah menggunakan micro frontend dalam tahun sebelumnya, dibandingkan dengan 75.4% di 2022. Data State of Frontend
Mungkin Anda sudah menghadapi masalah ini. Tiga tim produk berbagi repositori frontend dan menunggu kereta rilis yang sama, meskipun satu tim sedang mengubah checkout, tim lain sedang memperbarui profil, dan tim ketiga sedang mengatur halaman pemasaran. Arsitektur micro frontend memisahkan area produk tersebut sehingga tim dapat mengelola, menguji, dan merilis mereka secara independen sementara pengguna masih mengalami satu aplikasi.
Perbedaan ini sangat penting. Micro frontend bukanlah folder, komponen, atau bundle yang lebih kecil. Tujuan utama mereka adalah ketidakbergantungan organisasi dan rilisyang didukung oleh batasan teknis yang membuat kepemilikan eksplisit. Arsitektur ini dapat menghilangkan bottleneck koordinasi, tetapi juga memperkenalkan tanggung jawab integrasi waktu eksekusi, pengelolaan dependensi, pengujian, keamanan, dan kinerja.
Isi Kandungan
- Konsep Micro Frontend yang Perlu Dipahami
- Bagaimana Arsitektur Micro Frontend Berfungsi
- Menggambarkan Pola-Pola Micro Frontend Utama
- Manfaat, Kompromi, dan Risiko yang Tersembunyi
- Mengembangkan dan Mengimpor Praktik Pengujian
- Menggunakan Frontend Mikro di Capacitor dan Electron
- Mengapa Memilih Frontend Mikro
Mengerti Konsep Frontend Mikro
Dari Satu Frontend ke Beberapa Aplikasi yang Dimiliki
A frontend tradisional sering memiliki satu repositori, satu pembangunan, dan satu batas pengiriman. Bahkan jika code dibagi menjadi folder fitur bersih, tim di balik folder tersebut masih mungkin bergantung pada pipeline dan jadwal rilis yang sama. Perubahan kecil di satu area dapat memicu pembangunan aplikasi penuh, pengujian regresi bersama, dan koordinasi di setiap tim.
A micro frontend membagi aplikasi browser sekitar kemampuan bisnis . Tim pembayaran memiliki pembayaran, tim profil memiliki pengaturan akun, dan tim pemasaran memiliki konten promosi. Setiap bagian dapat memiliki kodebase, proses pengiriman, dan ritme rilis sendiri, kemudian menjadi bagian dari pengalaman yang lebih besar melalui lapisan shell atau komposisi.
Martin Fowler mendefinisikan pola tersebut sebagai Stilah arsitektur di mana aplikasi frontend yang dapat diaktifkan secara independen disusun menjadi keseluruhan yang lebih besar. dalam panduan arsitektur micro frontends dasar Arsitektur Mikro Frontend. The phrase “independently deliverable” carries more weight than “frontend applications.” Without an independent deployment boundary, you may have a modular monolith rather than a micro frontend system.
Analogi toko yang terintegrasi
Bayangkan sebuah toko department. Satu tim mengelola depan toko, tim lain mengoperasikan kasir, dan tim lain mengurus pengembalian barang. Pembeli melihat satu toko, tapi setiap area memiliki proses, tanggung jawab, dan staf yang berbeda. Micro frontend bekerja sama: browser menampilkan satu pengalaman produk sementara beberapa tim mengoperasikan area antarmuka yang berbeda di balik layar.
Aplikasi shell biasanya mengontrol kerangka yang dibagikan, navigasi, konteks autentikasi, dan keputusan jalur. Micro frontend mengontrol halaman atau kemampuan di dalam kerangka tersebut. Tim-setim menyetujui batasan antara mereka, tapi mereka tidak perlu berbagi setiap detail implementasi.
Istilah ini terkait dengan ekstensi pemikiran microservices ke browser after Thoughtworks highlighted it in its November 2016 Technology Radar. Fowler later documented its progression from Assess to Trial and then Adopt, which describes the pattern’s movement from an emerging technique toward a more established architectural option. For a broader practical overview of pengembangan web yang dapat diperluas oleh NerdifyDengan demikian, perbandingan pola dapat dibuat dengan pendekatan lain seperti arsitektur plugin, yang dibahas dalam artikel ini plugin architecture guide.
Kesimpulan penting adalah bahwa micro frontend bukanlah upgrade default untuk setiap antarmuka. Mereka berarti ketika batasan tim dan batasan rilis menciptakan rasa sakit nyata. Biaya yang diakui hanya ketika independensi itu layak mengelola lebih banyak kontrak, aset, mode gagal waktu eksekusi, dan alat operasional.
Bagaimana Arsitektur Micro Frontend Berfungsi
Shell dan fragmennya
Sebuah sistem yang berfungsi biasanya dimulai dengan shell aplikasi, juga disebut sebagai kontainer atau pengatur. Shell menampilkan tata letak umum, menetapkan routing, menyediakan konteks autentikasi, dan menyediakan elemen antarmuka bersama seperti navigasi atau peringatan. Shell juga menentukan micro frontend mana yang akan 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 menyusun bagian-bagian tersebut di browser, baik ketika halaman dimuat atau ketika rute memerlukan mereka.
Batasan tidak berguna kecuali tim dapat bergantung padanya. Shell dan fragmen masing-masing memerlukan kontrak eksplisit yang mencakup perilaku pasang, kepemilikan rute, status muat, penanganan kesalahan, token desain, harapan aksesibilitas, dan versi dependensi yang didukung.
Aturan praktis: Bagikan kontrak dan primitif visual dengan sengaja. Jangan bagikan detail implementasi waktu eksekusi hanya karena dua tim saat ini menggunakan framework yang sama.
Komunikasi tanpa mereproduksi monolit
Fragmen kadang-kadang perlu berkomunikasi. Bagian checkout mungkin perlu tahu bahwa pengguna telah masuk, sementara bagian profil mungkin perlu mempublikasikan event akun diperbarui. Tim dapat menggunakan event browser khusus, toko bersama, parameter URL, atau layanan yang diinjeksikan.
Setiap pilihan menciptakan profil koneksi yang berbeda:
- Event khusus tetapkan kepemilikan terpisah, tetapi tim harus mendokumentasikan nama event, bentuk payload, dan waktu.
- Toko bersama sederhanakan koordinasi state, namun mereka dapat mereproduksi grafik ketergantungan sentral yang arsitektur itu bermaksud untuk mengurangi.
- Parameter URL berfungsi dengan baik untuk navigasi dan state yang dapat dibagikan, meskipun mereka tidak cocok untuk setiap interaksi.
- Layanan yang diinjeksikan menyediakan kemampuan yang dikendalikan, tetapi shell harus mempertahankan kontrak layanan tersebut.
Shell harus mengkoordinasikan hanya apa yang dimiliki oleh aplikasi keseluruhan. Jika menjadi tanggung jawab untuk setiap fragmen’s state dan aturan bisnis, maka telah menjadi monolit yang terdistribusi dengan proses pengembangan 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 memberikan komposisi yang dapat diandalkan.
Menggambarkan Pola Dasar Micro Frontend
No single integration mechanism solves every micro frontend problem. Choose by comparing isolation, communication, dependency sharing, browser behavior, and operational ownership rather than selecting the most fashionable tool.
| Isolasi | context | Model Integrasi | Ketergantungan Bersama | Kinerja | Terbaik Sesuai |
|---|---|---|---|---|---|
| Iframes | Proses yang kuat dan isolasi dokumen | Proses yang Kuat dan Isolasi Dokumen | Dokumen Terintegrasi dengan Komunikasi Antar-Framewok | Dapat menambahkan beban penggunaan sumber daya | Dapat Menambahkan Beban Pengisian dan Komunikasi |
| Komponen Web | Elemen yang diapit dan gaya Shadow DOM yang digunakan di mana-mana | Elemen kustom yang dimount oleh shell | Token desain bersama dan API browser | Sering prediktif, tetapi tergantung pada berat komponen | Tim yang memerlukan fleksibilitas kerangka berdasarkan standar |
| Modul Federasi | Isolasi runtime moderat | Modul remote yang dimuat dan dimount pada waktu runtime | Ketergantungan yang diatur secara eksplisit atau dikemas | Menghemat waktu ketika pengisian dan deduplikasi dikontrol | Aplikasi yang terintegrasi erat dengan rilis independen |
| single-spa | Pembatasan orkestrasi daripada model isolasi lengkap | Aplikasi yang terdaftar melalui hook siklus hidup | Terletak pada aplikasi dan konfigurasi root | Terletak pada aturan pengisian dan komposisi framework | Orkestrasi multi-framework dengan aktivasi berdasarkan rute |
Iframe
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 antar jendela dapat membuat jalur komunikasi yang dikendalikan.
Isolasi tersebut membuat iframe berguna untuk sistem legacy, pengalaman mitra, atau konten yang harus tetap terpisah. Biaya muncul 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 pengisian, batas kesalahan, dan token desain bersama.
Pilihan ini berfungsi baik ketika tim ingin fleksibilitas framework tanpa membuat browser memuat runtime aplikasi penuh untuk setiap potongan. Ini tidak secara otomatis menyelesaikan ukuran dependensi, komunikasi keadaan, atau pengelolaan. Sebuah elemen kustom masih dapat mengandung aplikasi besar dengan kompleksitas operasional sendiri.
Federasi Modul
Module Federation, yang diperkenalkan dengan Webpack 5 dan didukung oleh tools seperti Vite dan Rspack, memuat modul yang dikompilasi dari entri remote pada saat runtime. Ini menawarkan integrasi yang erat, yang membuat komponen yang dibagikan dan navigasi yang disinkronisasi terasa lebih alami daripada yang seringkali terjadi dengan iframes.
Kenyamanan tersebut menciptakan tanggung jawab. Tim perlu memiliki 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 provides useful context for separating deployment independence from simple code decomposition.
single-spa
single-spa berfungsi sebagai orchestrator yang netral terhadap framework. Tim mendaftarkan aplikasi dan hook siklus hidup, kemudian konfigurasi root yang aktif menyalakannya berdasarkan 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 ini. Misalnya, konfigurasi root single-spa mungkin mengkoordinasikan rute, Module Federation mungkin menyediakan modul remote, dan komponen web mungkin mendefinisikan permukaan pemasangan publik. Gabungan tersebut dapat kuat, tetapi setiap lapisan yang ditambahkan meningkatkan jumlah perilaku yang pengembang harus memahami dan menguji.
Kelebihan, Keterbatasan, dan Risiko yang Tersembunyi
Frontend mikro memindahkan keputusan di batas-batas. Mereka dapat mengurangi radius ledakan dari rilis dan memberikan tim lebih banyak kontrol, tetapi sistem harus mengelola lebih banyak artefak, kontrak, dan kondisi waktu eksekusi.
| Dimensi | Manfaat | Tukar Menukar / Risiko Tersembunyi |
|---|---|---|
| Otonomi tim | Tim memiliki potongan bisnis dari awal hingga akhir | Tim harus mempertahankan pipa yang terpisah, tanggung jawab on-call, dan disiplin rilis |
| Pengembangan | Sebuah fragmen dapat berlayar tanpa membangun antarmuka penuh kembali | Rilis menjadi tidak atomik, sehingga versi yang tidak kompatibel dapat bertemu di produksi |
| Pengisolasi gagal | Sebuah remote gagal dapat diisolasi dengan fallback | Keterbatasan error yang buruk masih dapat membuat navigasi atau perjalanan kritis tidak dapat digunakan |
| Kinerja | Pemuatan santai dan paket awal yang lebih kecil dapat membantu aliran umum | Banyak permintaan, kerangka kerja yang diulang code, dan inisialisasi remote dapat merusak kinerja waktu eksekusi |
| Pilihan Teknologi | Tim tim dapat menggunakan berbagai framework di mana batasan memungkinkannya | Mengembangkan, aksesibilitas, konsistensi desain, dan merekrut karyawan menjadi lebih sulit di atas stack campuran |
| Security | Sebuah batasan dapat membatasi berbagi implementasi langsung | Bungkus dapat menjalankan remote code yang belum cukup diverifikasi |
| context | Standar bersama dapat menjaga produk yang konsisten | Desain sistem, aturan ketergantungan, kontrak, dan dukungan platform memerlukan koordinasi terus-menerus |
Tagihan kinerja
Potongan independen biasanya menghasilkan aset yang dibangun secara terpisah. Tanpa aturan muat yang hati-hati, browser mungkin meminta file lebih banyak, menginisialisasi lebih banyak code, atau mengunduh dependensi framework duplikat. Panduan kinerja untuk micro frontends menekankan muatan pada permintaan, berbagi dependensi yang hati-hati, caching modul-level, dan isolasi gagal.
Desain yang praktis dimulai dengan dasar untuk aplikasi yang ada. Ukur startup jalur, komposisi bundle, muatan jarak jauh, inisialisasi, dan gagal yang terlihat oleh pengguna. Kemudian tetapkan anggaran untuk shell dan setiap potongan yang berlalu lintas tinggi. Muatan santai hanya membantu jika aplikasi tidak menghalangi perjalanan kritikal pada rantai panjang modul jarak jauh.
Keamanan di sambungan
Modul jarak jauh tidak otomatis aman karena memiliki repositori 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 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 ke kontrak, otomatisasi, observabilitas, dan pengelolaan.
Tim juga membutuhkan kepemilikan yang jelas untuk dependensi yang dibagikan, tinjauan aksesibilitas, tanggapan insiden, dan keputusan rollback. Jika tidak ada 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.
Bangun sistem pengujian 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 mencakup routing, transisi autentikasi, navigasi bersama, gagal muat, dan kombinasi versi. Uji akhir ke akhir berada di atas karena mereka memvalidasi perjalanan lengkap seperti browsing produk, masuk, dan menyelesaikan checkout di beberapa potongan yang dihantar secara independen.
Kontrol permukaan rilis
Gunakan manifest versi sehingga shell dapat mengidentifikasi artefak fragmen yang tepat yang dimuat. Manifest juga memberikan operator tempat untuk memasang versi yang baik ketika rilis remote menyebabkan kesalahan.
Kontrol yang berguna termasuk:
- Flag fitur: Aktifkan fragmen baru untuk audiens internal atau rute tertentu sebelum ekspose luas.
- Pengiriman canary: Arahkan audiens terbatas ke artefak baru sambil memantau kesalahan browser, gagal muat, dan aksi bisnis utama.
- 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 pembangunan manual.
Tim harus menguji shell dan fragmen bersama-sama di lingkungan seperti 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 untuk membandingkan jalur baru dengan implementasi yang ada sebelum membuat jalur baru menjadi default.
Pertimbangkan aplikasi komersial dengan tim katalog, akun, dan checkout yang terpisah. Shell mengelola navigasi dan autentikasi, tim katalog mengelola browsing produk, tim akun mengelola pengaturan profil, dan tim checkout mengelola alur pembayaran dan keranjang. Setiap tim menerbitkan artefaknya sendiri, sementara tes kontrak melindungi kesepakatan jalur dan acara.
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 seluruh organisasi 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 waktu 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 ditandatanganiverifikasi mereka sebelum aktivasi, mendukung saluran rilis untuk peluncuran yang dipersiapkan, menerapkan update pada peluncuran berikutnya daripada mengganggu sesi aktif, dan menyediakan perlindungan rollback otomatis dengan reverter atom.
Kontrol-kontrol tersebut dapat dipetakan secara alami ke pengiriman frontend mikro. Shell mobile atau desktop dapat memasang manifest, mengambil fragmen yang kompatibel, memverifikasi tanda tangan, dan mengaktifkannya hanya ketika bundel lengkap tersedia. Jika peluncuran berikutnya mendeteksi gagal, pembaruan 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 update waktu nyata untuk aplikasi CapacitorJS dan Electron memublikasikan bundle web yang ditandatangani, mendukung saluran yang spesifik, menerapkan update 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 asli.
Penggunaan wrapper asli 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.
- Compatibility: Bundle web mungkin bergantung pada perilaku jembatan asli yang tidak didukung oleh binary yang terinstal.
- Keamanan: Remote code harus diotentikkan, integritasnya diperiksa, dan diotorisasi untuk konteks aplikasi.
- Pulih: Perluan shell harus dapat menolak bundle yang tidak valid dan memulihkan versi yang berfungsi tanpa memerlukan distribusi toko segera.
- Keamanan Sesi: Mengupdate selama proses pembayaran atau alur formulir dapat menciptakan keadaan tidak konsisten, sehingga aktivasi pada peluncuran berikutnya lebih aman daripada mengganggu pekerjaan aktif.
Model ini memperkuat pengembalian ke awal ketika platform pengiriman menawarkan aktivasi atomik dan metrik rilis yang rinci. Ini mempersulit arsitektur ketika tim asumsikan bahwa independensi web menghilangkan perencanaan kompatibilitas native. Shell native tetap menjadi batasan 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 lama 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 build tunggal 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 dapat diandalkan, observabilitas, pengujian kontrak, dan prosedur pengembalian ke awal. 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 diajukan?
- Batasan: Mengapa shell dan slice dapat berkomunikasi melalui kontrak yang stabil?
- Perlu rilis: Apakah tim memerlukan untuk mengeluarkan secara independen?
- Siap untuk operasional: Apakah 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 jalur, 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 bisa 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.
