Micro frontend adalah antarmuka pengguna yang terdiri dari aplikasi frontend independen dan dapat di-deploy. Pendekatan ini secara resmi ditekankan oleh Thoughtworks pada 2016dan 2024 survey melaporkan bahwa 23.6% di antara responden telah menggunakan micro frontends dalam tahun sebelumnya, dibandingkan dengan 75.4% di 2022. State of Frontend data
Kamu mungkin sudah menghadapi masalah ini. Tiga tim produk berbagi satu repositori frontend dan menunggu kereta rilis yang sama, meskipun satu tim sedang mengubah checkout, tim lainnya sedang memperbarui profil, dan tim ketiga sedang menyesuaikan 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 itu penting. Micro frontends bukan hanya folder, komponen, atau bundle yang lebih kecil. Tujuan utama mereka adalah ketidakbergantungan organisasional dan rilis, 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.
Tabel Konten
- context: Halaman/area: Situs web pemasaran Capgo. Peran: Label UI singkat atau item navigasi. Dilihat di: halaman blog/[slug].astro. Kunci pesan `table_of_contents` (Tabel Konten).
- Bagaimana Arsitektur Micro Frontend Bekerja
- Menggambarkan Pola-Pola Micro Frontend Utama
- Manfaat, Kompromi, dan Risiko-Risiko yang 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 milik
Frontend tradisional sering memiliki satu repositori, satu build, 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.
Micro Frontend membagi aplikasi browser sekitar kemampuan bisnisTimbalan timbalan checkout mengelola checkout, timbalan profil mengelola pengaturan akun, dan tim pemasaran mengelola konten promosi. Setiap bagian dapat memiliki kodebase, proses pengiriman, dan ritme rilis sendiri, kemudian menjadi bagian dari pengalaman yang lebih besar melalui lapisan atau layer komposisi.
Martin Fowler mendefinisikan pola tersebut sebagai “suatu gaya arsitektur di mana aplikasi frontend yang dapat dihasilkan secara independen dikomposisikan menjadi keseluruhan yang lebih besar” di panduan arsitektur micro frontendsnya yang mendirikan . Kalimat “dapat dihasilkan secara independen” membawa lebih banyak bobot daripada “aplikasi frontend.” Tanpa batasan pengiriman independen, Anda mungkin memiliki monolit modular daripada sistem micro frontend.Karyawan kantor yang tertekan duduk di meja menahan kertas yang mewakili tim pengembangan micro frontend di kantor.
Pikirkan sebuah toko departemen. Satu tim mengelola depan toko, tim lain mengelola kasir, dan tim lain mengelola pengembalian barang. Pengunjung melihat satu toko, tetapi setiap area memiliki proses, tanggung jawab, dan staf yang berbeda. Micro frontend bekerja sama: browser menampilkan pengalaman produk yang sama sementara beberapa tim mengoperasikan area antarmuka yang berbeda di balik layar.
Lapisan aplikasi biasanya mengelola frame bersama, navigasi, konteks autentikasi, dan keputusan jalur. Micro frontend mengelola halaman atau kemampuan di dalam frame tersebut. Tim setuju pada batasan antara mereka, tetapi mereka tidak perlu berbagi setiap detail implementasi.
__CAPGO_KEEP_0__
Istilah ini terkait dengan ekstensi pemikiran microservices ke browser setelah Thoughtworks menyorotinya dalam Radar Teknologi bulan November 2016. Fowler kemudian mendokumentasikan kemajuan dari Assess ke Trial dan kemudian Adopt, yang menjelaskan pola pergerakan dari teknik yang sedang berkembang menuju opsi arsitektur yang lebih terestablis. Untuk tinjauan praktis yang lebih luas tentang pengembangan web yang skalabel oleh Nerdify , membantu membandingkan pola dengan pendekatan berdekatan seperti arsitektur plugin, yang dibahas dalam guide arsitektur plugin .
Pesan penting adalah bahwa micro frontend bukanlah upgrade default untuk setiap antarmuka. Mereka berarti ketika batasan tim dan batasan rilis menciptakan rasa sakit nyata. Biaya hanya dibayarkan ketika independensi itu layak 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 app shell , juga disebut sebagai kontainer atau pengatur. Shell menampilkan tata letak umum, menetapkan routing, menyediakan konteks autentikasi, dan menyediakan elemen antarmuka yang dibagikan seperti navigasi atau pemberitahuan. Ia juga menentukan micro frontend mana yang harus dimuat dan di mana fragmen itu harus dimount.
Setiap fragmen adalah aplikasi yang dipelihara secara independen. Mereka mungkin hidup di repositori yang terpisah, menggunakan CI pipeline sendiri, menerbitkan versi sendiri, dan menampilkan bundle, fragmen, komponen web, atau modul jarak. Shell komponen tersebut di browser, baik ketika halaman dimuat atau ketika jalur memerlukan mereka.
Batasan tidak berguna jika tim tidak dapat bergantung padanya. Shell dan setiap fragmen memerlukan kontrak eksplisit yang mencakup perilaku mount, kepemilikan jalur, status muat, pengelolaan 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. Slicing checkout mungkin perlu tahu bahwa pengguna telah masuk, sementara slicing profil mungkin perlu menerbitkan event akun diperbarui. Tim dapat menggunakan acara browser khusus, penyimpanan 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 payload, dan waktu.
- Penyimpanan bersama Mengurangi koordinasi status, tetapi mereka dapat mereproduksi grafik dependensi sentral yang arsitektur itu bermaksud untuk mengurangi.
- Parameter URL Menggunakan parameter URL dapat berfungsi dengan baik untuk navigasi dan keadaan yang dapat dibagikan, meskipun tidak cocok untuk setiap interaksi.
- Pelayanan yang diinjeksikan Menghadirkan kemampuan yang dikendalikan, tetapi shell harus mempertahankan kontrak layanan tersebut.
Shell harus mengkoordinasikan apa yang dimiliki oleh aplikasi keseluruhan. Jika menjadi tanggung jawab untuk setiap fragmen dan aturan bisnis, maka telah menjadi monolit yang terdistribusi dengan proses pengiriman yang lebih rumit.
Progressi sejarah yang dokumentasi oleh Fowler menjelaskan mengapa pola ini sering dibandingkan dengan mikroservis. Kedua pendekatan memisahkan kepemilikan dan pengiriman, tetapi mikro frontend menerapkan independensi tersebut pada interface browser. Dalam tooling saat ini, Penggunaan Federasi Modul Sudah menjadi pilihan yang populer, sementara single-spa tetap menjadi pilihan orkestrasi untuk tim yang ingin registrasi aplikasi berdasarkan siklus hidup.
Contoh, tim pembayaran mungkin merilis perbaikan aliran pembayaran tanpa membangun kembali fragmen katalog. Tim katalog dapat terus melanjutkan dengan siklus rilis yang lebih lambat karena shell memuat setiap fragmen yang disetujui sesuai dengan konfigurasi waktu eksekusi. Batas pengiriman independen tersebut, bukan penampilan visual komponen yang terpisah, adalah keuntungan utama arsitektur.
Tim yang mengevaluasi platform lingkungan juga harus mempertimbangkan Infrastruktur aplikasi untuk sistem frontendKarena repositori dan kerangka kerja sendiri tidak akan memberikan komposisi yang dapat diandalkan.
Membandingkan Pola-Pola Dasar Micro Frontend
Tidak ada mekanisme integrasi tunggal yang dapat menyelesaikan semua masalah micro frontend. Pilih dengan membandingkan isolasi, komunikasi, pengiriman dependensi, perilaku browser, dan kepemilikan operasional daripada memilih alat yang paling populer.
| Pola | Isolasi | context: Halaman/area: Capgo Builder / produk halaman native cloud build. Peran: Label UI singkat atau item navigasi. Dilihat di: halaman native-build.astro. Kunci pesan `native_build_v2_trust_iso_lbl` (Native Build V2 Trust Iso Lbl). | Model Integrasi | Pengiriman Dependensi Bersama | Kinerja |
|---|---|---|---|---|---|
| context: Halaman/area: Bagian masalah/solusi homepage. Peran: Judul bagian atau halaman. Dilihat di: halaman premium-support.astro. Kunci pesan `ps_help_performance_title` (Ps Help Performance Title). | Pilihan Terbaik | Iframe | Proses dan Dokumentasi yang Kuat dengan Isolasi | Dapat menambahkan beban pengisian dan komunikasi | Pengalaman tidak dipercaya, 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 memerlukan fleksibilitas kerangka berdasarkan standar |
| Modul Federasi | Pengisolasi waktu eksekusi moderat | Modul remote yang dimuat dan dimount pada waktu eksekusi | Ketergantungan yang disepakati atau dibundel secara eksplisit | Effisien ketika pengisian dan deduplikasi dikendalikan | Aplikasi yang sangat terintegrasi dengan rilis independen |
| single-spa | Pemisahan batas orkestrasi daripada model isolasi lengkap | Aplikasi yang terdaftar melalui hook siklus hidup | Tergantung pada aplikasi dan konfigurasi root | Tergantung pada aturan pengisian 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 jendela dapat membuat jalur komunikasi yang dikendalikan.
Ayunan isolasi membuat iframes 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 host dan aplikasi yang diintegrasikan tidak koordinasi dengan hati-hati.
Komponen web
Komponen web menggunakan standar browser daripada memerlukan setiap tim untuk menerima kerangka kerja yang sama. Elemen kustom mendefinisikan permukaan pemasangan stabil, dan DOM Bayangan dapat membatasi kebocoran gaya. Shell masih perlu menghandle routing aplikasi, status muatan, batas kesalahan, dan token desain bersama.
Opsi ini berfungsi baik ketika tim ingin fleksibilitas kerangka kerja tanpa membuat browser memuat runtime aplikasi seluruh untuk setiap potongan. Ini tidak secara otomatis menyelesaikan ukuran dependensi, komunikasi keadaan, atau pengelolaan. Elemen kustom masih dapat mengandung aplikasi besar dengan kompleksitas operasional sendiri.
Modul Federasi
Modul Federasi, yang diperkenalkan dengan Webpack 5 dan didukung oleh alat seperti Vite dan Rspack, memuat modul yang dikompilasi dari entri remote pada waktu runtime. Ini menawarkan integrasi yang erat, yang membuat komponen bersama dan navigasi yang koordinasi terasa lebih alami daripada yang sering terjadi dengan iframes.
Kenyamanan ini menciptakan tanggung jawab. Tim perlu interface yang kompatibel, aturan untuk dependensi bersama, 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 pengembangan dari dekomposisi sederhana code.
single-spa
single-spa berperan sebagai pengatur yang netral terhadap framework. Tim mendaftarkan aplikasi dan hook siklus hidup, kemudian konfigurasi root aktifkan mereka berdasarkan rute atau kondisi lainnya. Ini dapat mengkoordinasikan aplikasi yang dibangun dengan framework yang berbeda, tetapi tidak menghilangkan kebutuhan untuk kontrak, kebijakan ketergantungan, anggaran kinerja, atau kontrol keamanan.
Tim dapat menggabungkan mekanisme ini. Misalnya, root single-spa mungkin mengkoordinasikan rute, Module Federation mungkin menyediakan modul remote, dan komponen web mungkin mendefinisikan permukaan pemasangan publik. Gabungan ini dapat sangat kuat, tetapi setiap lapisan yang ditambahkan meningkatkan jumlah perilaku yang pengembang harus memahami dan menguji.
Penghematan, Kompromi, dan Risiko yang Tersembunyi
Dimensi
| Benefit | Kompromi / Risiko yang Tersembunyi | Otonomi tim |
|---|---|---|
| Tim memiliki kontrol atas bagian bisnis dari awal hingga akhir | Tim harus mempertahankan pipeline yang terpisah, kepemilikan on-call, dan disiplin rilis | Pengembangan |
| Fragment dapat dikirimkan tanpa membangun antarmuka penuh kembali | Pengembangan | Rilis menjadi tidak atomik, sehingga versi yang tidak kompatibel dapat bertemu di produksi |
| Isolasi gagal | Jaringan remote yang gagal dapat diisolasi dengan fallback | Pembatasan kesalahan yang buruk masih dapat membuat navigasi atau perjalanan kritis tidak dapat digunakan |
| Kinerja | context | More requests, duplicated framework code, and remote initialization can hurt runtime performance |
| Pemuatan yang ceroboh dan paket awal yang lebih kecil dapat membantu aliran umum | Permintaan yang lebih banyak, kerangka yang diulang __CAPGO_KEEP_0__, dan inisialisasi remote dapat merugikan kinerja waktu eksekusi | Pilihan teknologi |
| Tim dapat menggunakan kerangka yang berbeda di mana batasan memungkinkan | Debugging, aksesibilitas, konsistensi desain, dan perekrutan menjadi lebih sulit di antara stack campuran yang berbeda-beda | Shell mungkin menjalankan code remote yang belum cukup diverifikasi |
| Governance | Standar yang dibagikan dapat menjaga produk yang konsisten | Sistem desain, aturan ketergantungan, kontrak, dan dukungan platform memerlukan koordinasi yang terus-menerus |
Tagihan kinerja
Porsi independen biasanya menghasilkan aset yang dibangun secara terpisah. Tanpa aturan muat yang hati-hati, browser mungkin meminta file tambahan, menjalankan lebih banyak code, atau mengunduh dependensi kerangka kerja duplikat. Panduan kinerja untuk micro frontends menekankan muatan pada permintaan, berbagi dependensi dengan hati-hati, caching modul-level, dan isolasi gagal.
Desain yang praktis dimulai dengan basis untuk aplikasi yang ada. Ukur startup rute, komposisi bundle, muatan remote, inisialisasi, dan gagal yang terlihat pengguna. Kemudian tetapkan anggaran untuk shell dan setiap slice yang berlalu lintas tinggi. Muatan yang santai hanya membantu jika aplikasi tidak menghalangi perjalanan kritikal pada rantai panjang modul remote.
Keamanan di sambungan
Modul remote 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 runtime.
Perbedaan versi menciptakan kelas risiko lainnya. Fragmen mungkin berfungsi sendiri tetapi gagal ketika bertemu shell versi yang berbeda, library bersama, set token desain, atau payload acara. Guidanannya Arsitektur Nx Mengidentifikasi koordinasi, konfigurasi lingkungan, efisiensi aplikasi, dan kembali kegunaan sebagai tantangan yang terus-menerus.
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 dengan cara yang berbeda, dan pengguna akan mengalami ketidakkonsistenan yang dihasilkan sebagai satu aplikasi yang rusak.
Pengujian, Pengembangan, dan Praktik Pindah
Pengujian harus mencerminkan cara aplikasi berjalan. Fragment yang melewati uji unit sendiri masih bisa gagal ketika shell menyediakan jalur yang berubah, keadaan autentikasi yang tidak terduga, atau dependensi yang dibagikan yang berbeda.
Buatlah sistem pengujian yang berlapis
Mulai dengan uji isolasi untuk setiap fragment. Uji ini memvalidasi rendering, aturan bisnis, perilaku tombol, status muat, dan penanganan kesalahan lokal tanpa memerlukan shell yang lengkap.
Uji kontrak berada di atasnya. Mereka memverifikasi antarmuka antara shell dan fragment, termasuk masukan untuk memasang, pola jalur, event yang diemitsi, payload yang diharapkan, asumsi autentikasi, dan perilaku fallback. Uji 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 browsing 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 remote menyebabkan kesalahan.
Kontrol yang berguna termasuk:
- Bendera fitur: Aktifkan fragmen baru untuk audiens internal atau rute yang dipilih 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 sebagai aksi operasional, bukan merekonstruksi manual.
Tim harus menguji shell dan fragmen bersama-sama di lingkungan produksi yang mirip. Jalankan sukses 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.
Perhatikan aplikasi perdagangan 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 keranjang dan alur pembayaran. 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 saat runtime daripada mengintegrasikan setiap perubahan antarmuka 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 menentukan dari mana fragmen berasal, versi mana yang disetujui, dan apa yang harus dilakukan oleh aplikasi jika langkah fetch atau verifikasi gagal.
Perbarui Hidup dan Rollback
Sistem perbarui hidup harus menganggap artefak frontend sebagai perangkat lunak yang dapat dirilis. Sistem tersebut harus mengirimkan bundel yang ditandatanganimengverifikasinya sebelum aktivasi, mendukung saluran rilis untuk peluncuran yang dipersiapkan, menerapkan perbarui 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, mengverifikasi tandatangan, dan mengaktifkannya hanya ketika bundel lengkap tersedia. Jika peluncuran berikutnya mendeteksi gagal, pembarui dapat kembali ke keadaan yang baik sebelumnya daripada meninggalkan pengguna dengan antarmuka yang sebagian diperbarui.
Capgo is one option for this delivery model. Its live-update platform for CapacitorJS and Electron apps publishes signed web bundles, supports targeted channels, applies updates on next launch, and provides logs, version history, adoption and failure metrics, rollback protection, CI/CD integrations, and an API. Teams considering the native bridge should also understand how Capacitor connects web and native code.
Diagram yang menggambarkan cara menggunakan micro frontends dengan __CAPGO_KEEP_0__ atau shell aplikasi native Electron.
Apa saja yang berubah dalam shell asli.
- Penggunaan wrapper asli memperkenalkan keterbatasan yang aplikasi browser hanya mungkin tidak menghadapi: Koneksi:
- Fragment mungkin tidak tersedia ketika perangkat offline, sehingga shell memerlukan artefak yang dicache atau fallback lokal. Kemampuan kompatibilitas:
- Bundle web mungkin bergantung pada perilaku jembatan asli yang tidak didukung oleh binary yang terinstal. Remote code must be authenticated, integrity-checked, and authorized for the application context.
- Remote __CAPGO_KEEP_0__ harus diotentikkan, integritasnya dicek, dan diotorisasi untuk konteks aplikasi. Shell harus dapat menolak bundle yang tidak valid dan memulihkan versi yang berfungsi tanpa memerlukan distribusi toko segera.
- Keselamatan 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 rollback ketika platform pengiriman menawarkan aktivasi atomik dan metrik rilis yang rinci. Hal ini memperumitkan arsitektur ketika tim asumsikan bahwa independensi web menghilangkan perencanaan kompatibilitas native. Shell native tetap menjadi 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 build tunggal dengan baik.
Hindari hal ini ketika tim kecil dapat dengan nyaman mengelola satu frontend, ketika domain memiliki keadaan mutable yang luas, atau organisasi Anda tidak memiliki prosedur CI yang andal, observabilitas, pengujian kontrak, dan prosedur rollback. Interface yang terdistribusi tanpa dasar-dasar tersebut tidak menciptakan otonomi. Malah menciptakan tempat-tempat baru 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?
- Kebutuhan rilis: Apakah tim memerlukan pengiriman independen?
- Siap untuk operasional: Apakah Anda dapat memantau, menguji, memasang, dan mengembalikan fragmen?
- Nilai pengguna: Apakah pemisahan 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 muatan, 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 Anda, 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.
