Jelajahi dunia frontend microservices, fokus pada penemuan layanan dan teknik komunikasi yang efektif untuk membangun aplikasi web yang terukur dan mudah dipelihara.
Frontend Microservices: Strategi Penemuan Layanan dan Komunikasi
Arsitektur microservice telah merevolusi pengembangan backend, memungkinkan tim untuk membangun layanan yang terukur, tangguh, dan dapat di-deploy secara independen. Sekarang, pola arsitektur ini semakin banyak diadopsi di frontend, yang memunculkan frontend microservices, juga dikenal sebagai micro frontends. Artikel ini membahas aspek penting dari penemuan layanan dan komunikasi dalam arsitektur frontend microservice.
Apa itu Frontend Microservices?
Frontend microservices (atau micro frontends) adalah pendekatan arsitektur di mana aplikasi frontend diuraikan menjadi unit-unit yang lebih kecil, dapat di-deploy secara independen, dan mudah dipelihara. Setiap micro frontend biasanya dimiliki oleh tim yang terpisah, memungkinkan otonomi yang lebih besar, siklus pengembangan yang lebih cepat, dan penskalaan yang lebih mudah. Tidak seperti frontend monolitik, di mana semua fitur terikat erat, micro frontends mempromosikan modularitas dan decoupling.
Manfaat Frontend Microservices:
- Deployment Independen: Tim dapat men-deploy micro frontends mereka tanpa memengaruhi bagian lain dari aplikasi, mengurangi risiko deployment dan memungkinkan iterasi yang lebih cepat.
- Keberagaman Teknologi: Setiap tim dapat memilih tumpukan teknologi terbaik untuk micro frontend spesifik mereka, memungkinkan eksperimen dan inovasi.
- Skalabilitas yang Ditingkatkan: Micro frontends dapat diskalakan secara independen berdasarkan kebutuhan spesifik mereka, mengoptimalkan pemanfaatan sumber daya.
- Otonomi Tim yang Ditingkatkan: Tim memiliki kepemilikan penuh atas micro frontends mereka, yang mengarah pada peningkatan otonomi dan pengambilan keputusan yang lebih cepat.
- Pemeliharaan yang Lebih Mudah: Basis kode yang lebih kecil lebih mudah dipelihara dan dipahami, mengurangi risiko memasukkan bug.
Tantangan Frontend Microservices:
- Kompleksitas yang Meningkat: Mengelola banyak micro frontends bisa lebih kompleks daripada mengelola satu frontend monolitik.
- Penemuan dan Komunikasi Layanan: Mengimplementasikan mekanisme penemuan dan komunikasi layanan yang efektif sangat penting untuk keberhasilan arsitektur micro frontend.
- Komponen Bersama: Mengelola komponen dan dependensi bersama di seluruh micro frontends bisa menjadi tantangan.
- Optimalisasi Kinerja: Mengoptimalkan kinerja di beberapa micro frontends memerlukan pertimbangan yang cermat terhadap strategi pemuatan dan mekanisme transfer data.
- Pengujian Integrasi: Pengujian integrasi bisa lebih kompleks dalam arsitektur micro frontend, karena memerlukan pengujian interaksi antara beberapa unit independen.
Penemuan Layanan di Frontend Microservices
Penemuan layanan adalah proses menemukan dan terhubung ke layanan secara otomatis dalam sistem terdistribusi. Dalam arsitektur frontend microservice, penemuan layanan sangat penting untuk memungkinkan micro frontends berkomunikasi satu sama lain dan dengan layanan backend. Ada beberapa pendekatan untuk penemuan layanan di frontend microservices, masing-masing dengan kelebihan dan kekurangannya sendiri.
Pendekatan untuk Penemuan Layanan:
1. Konfigurasi Statis:
Dalam pendekatan ini, lokasi setiap micro frontend dikodekan secara permanen dalam file konfigurasi atau variabel lingkungan. Ini adalah pendekatan yang paling sederhana, tetapi juga yang paling tidak fleksibel. Jika lokasi micro frontend berubah, Anda perlu memperbarui file konfigurasi dan men-deploy ulang aplikasi.
Contoh:
const microFrontendConfig = {
"productCatalog": "https://product-catalog.example.com",
"shoppingCart": "https://shopping-cart.example.com",
"userProfile": "https://user-profile.example.com"
};
Kelebihan:
- Sederhana untuk diimplementasikan.
Kekurangan:
- Tidak terukur.
- Memerlukan deployment ulang untuk perubahan konfigurasi.
- Tidak tahan terhadap kegagalan.
2. Penemuan Layanan Berbasis DNS:
Pendekatan ini menggunakan DNS untuk menyelesaikan lokasi micro frontends. Setiap micro frontend diberi catatan DNS, dan klien dapat menggunakan kueri DNS untuk menemukan lokasinya. Pendekatan ini lebih fleksibel daripada konfigurasi statis, karena Anda dapat memperbarui catatan DNS tanpa men-deploy ulang aplikasi.
Contoh:
Dengan asumsi Anda memiliki catatan DNS yang dikonfigurasi seperti ini:
- product-catalog.microfrontends.example.com IN A 192.0.2.10
- shopping-cart.microfrontends.example.com IN A 192.0.2.11
Kode frontend Anda mungkin terlihat seperti ini:
const microFrontendUrls = {
"productCatalog": `http://${new URL("product-catalog.microfrontends.example.com").hostname}`,
"shoppingCart": `http://${new URL("shopping-cart.microfrontends.example.com").hostname}`
};
Kelebihan:
- Lebih fleksibel daripada konfigurasi statis.
- Dapat diintegrasikan dengan infrastruktur DNS yang ada.
Kekurangan:
- Memerlukan pengelolaan catatan DNS.
- Perubahan dapat lambat menyebar.
- Bergantung pada ketersediaan infrastruktur DNS.
3. Registri Layanan:
Pendekatan ini menggunakan registri layanan khusus untuk menyimpan lokasi micro frontends. Micro frontends mendaftarkan diri mereka dengan registri layanan saat mereka dimulai, dan klien dapat meminta registri layanan untuk menemukan lokasinya. Ini adalah pendekatan yang paling dinamis dan tangguh, karena registri layanan dapat secara otomatis mendeteksi dan menghapus micro frontends yang tidak sehat.
Registri layanan populer meliputi:
- Consul
- Eureka
- etcd
- ZooKeeper
Contoh (menggunakan Consul):
Pertama, micro frontend mendaftarkan dirinya dengan Consul saat startup. Ini biasanya melibatkan penyediaan nama micro frontend, alamat IP, port, dan metadata relevan lainnya.
// Contoh menggunakan Node.js dan pustaka 'node-consul'
const consul = require('consul')({
host: 'consul.example.com', // Alamat server Consul
port: 8500
});
const serviceRegistration = {
name: 'product-catalog',
id: 'product-catalog-1',
address: '192.168.1.10',
port: 3000,
check: {
http: 'http://192.168.1.10:3000/health',
interval: '10s',
timeout: '5s'
}
};
consul.agent.service.register(serviceRegistration, function(err) {
if (err) throw err;
console.log('Terdaftar di Consul');
});
Kemudian, micro frontends lain atau aplikasi utama dapat meminta Consul untuk menemukan lokasi layanan katalog produk.
consul.agent.service.list(function(err, result) {
if (err) throw err;
const productCatalogService = Object.values(result).find(service => service.Service === 'product-catalog');
if (productCatalogService) {
const productCatalogUrl = `http://${productCatalogService.Address}:${productCatalogService.Port}`;
console.log('URL Katalog Produk:', productCatalogUrl);
} else {
console.log('Layanan Katalog Produk tidak ditemukan');
}
});
Kelebihan:
- Sangat dinamis dan tangguh.
- Mendukung pemeriksaan kesehatan dan failover otomatis.
- Menyediakan titik kontrol pusat untuk manajemen layanan.
Kekurangan:
- Memerlukan deployment dan pengelolaan registri layanan.
- Menambah kompleksitas pada arsitektur.
4. API Gateway:
API gateway bertindak sebagai titik masuk tunggal untuk semua permintaan ke layanan backend. Ini dapat menangani penemuan layanan, perutean, otentikasi, dan otorisasi. Dalam konteks frontend microservices, API gateway dapat digunakan untuk merutekan permintaan ke micro frontend yang sesuai berdasarkan jalur URL atau kriteria lainnya. API Gateway mengabstraksi kompleksitas layanan individual dari klien. Perusahaan seperti Netflix dan Amazon secara ekstensif menggunakan API Gateway.
Contoh:
Bayangkan Anda menggunakan reverse proxy seperti Nginx sebagai API Gateway. Anda dapat mengonfigurasi Nginx untuk merutekan permintaan ke micro frontends yang berbeda berdasarkan jalur URL.
# konfigurasi nginx
http {
upstream product_catalog {
server product-catalog.example.com:8080;
}
upstream shopping_cart {
server shopping-cart.example.com:8081;
}
server {
listen 80;
location /product-catalog/ {
proxy_pass http://product_catalog/;
}
location /shopping-cart/ {
proxy_pass http://shopping_cart/;
}
}
}
Dalam konfigurasi ini, permintaan ke `/product-catalog/*` dirutekan ke upstream `product_catalog`, dan permintaan ke `/shopping-cart/*` dirutekan ke upstream `shopping_cart`. Blok upstream mendefinisikan server backend yang menangani permintaan.
Kelebihan:
- Titik masuk terpusat untuk semua permintaan.
- Menangani perutean, otentikasi, dan otorisasi.
- Menyederhanakan penemuan layanan untuk klien.
Kekurangan:
- Dapat menjadi bottleneck jika tidak diskalakan dengan benar.
- Menambah kompleksitas pada arsitektur.
- Memerlukan konfigurasi dan manajemen yang cermat.
5. Backend for Frontend (BFF):
Pola Backend for Frontend (BFF) melibatkan pembuatan layanan backend terpisah untuk setiap frontend. Setiap BFF bertanggung jawab untuk menggabungkan data dari beberapa layanan backend dan menyesuaikan respons dengan kebutuhan spesifik frontend. Dalam arsitektur micro frontend, setiap micro frontend dapat memiliki BFF sendiri, yang menyederhanakan pengambilan data dan mengurangi kompleksitas kode frontend. Pendekatan ini sangat berguna saat berhadapan dengan berbagai jenis klien (mis., web, seluler) yang memerlukan format data atau agregasi yang berbeda.
Contoh:
Bayangkan aplikasi web dan aplikasi seluler keduanya perlu menampilkan detail produk, tetapi mereka memerlukan data dan format yang sedikit berbeda. Alih-alih membuat frontend langsung memanggil beberapa layanan backend dan menangani transformasi data itu sendiri, Anda membuat BFF untuk setiap frontend.
BFF web mungkin menggabungkan data dari `ProductCatalogService`, `ReviewService`, dan `RecommendationService` dan mengembalikan respons yang dioptimalkan untuk ditampilkan di layar lebar. BFF seluler, di sisi lain, mungkin hanya mengambil data paling penting dari `ProductCatalogService` dan `ReviewService` untuk meminimalkan penggunaan data dan mengoptimalkan kinerja pada perangkat seluler.
Kelebihan:
- Dioptimalkan untuk kebutuhan frontend tertentu.
- Mengurangi kompleksitas di frontend.
- Memungkinkan evolusi independen dari frontend dan backend.
Kekurangan:
- Memerlukan pengembangan dan pemeliharaan beberapa layanan backend.
- Dapat menyebabkan duplikasi kode jika tidak dikelola dengan benar.
- Meningkatkan overhead operasional.
Strategi Komunikasi di Frontend Microservices
Setelah micro frontends ditemukan, mereka perlu berkomunikasi satu sama lain untuk memberikan pengalaman pengguna yang mulus. Ada beberapa pola komunikasi yang dapat digunakan dalam arsitektur frontend microservice.
Pola Komunikasi:
1. Komunikasi Langsung:
Dalam pola ini, micro frontends berkomunikasi langsung satu sama lain menggunakan permintaan HTTP atau protokol lainnya. Ini adalah pola komunikasi yang paling sederhana, tetapi dapat menyebabkan coupling yang ketat dan peningkatan kompleksitas. Ini juga dapat menyebabkan masalah kinerja jika micro frontends berlokasi di jaringan atau wilayah yang berbeda.
Contoh:
Satu micro frontend (mis., micro frontend daftar produk) perlu menampilkan jumlah keranjang belanja pengguna saat ini, yang dikelola oleh micro frontend lain (micro frontend keranjang belanja). Micro frontend daftar produk dapat langsung membuat permintaan HTTP ke micro frontend keranjang belanja untuk mengambil jumlah keranjang.
// Dalam micro frontend daftar produk:
async function getCartCount() {
const response = await fetch('https://shopping-cart.example.com/cart/count');
const data = await response.json();
return data.count;
}
// ... tampilkan jumlah keranjang di daftar produk
Kelebihan:
- Sederhana untuk diimplementasikan.
Kekurangan:
- Coupling yang ketat antara micro frontends.
- Kompleksitas yang meningkat.
- Potensi masalah kinerja.
- Sulit untuk mengelola dependensi.
2. Events (Publish/Subscribe):
Dalam pola ini, micro frontends berkomunikasi satu sama lain dengan menerbitkan dan berlangganan events. Saat micro frontend menerbitkan event, semua micro frontends lain yang berlangganan event tersebut menerima pemberitahuan. Pola ini mempromosikan decoupling dan memungkinkan micro frontends bereaksi terhadap perubahan di bagian lain dari aplikasi tanpa mengetahui detail perubahan tersebut.
Contoh:
Saat pengguna menambahkan item ke keranjang belanja (dikelola oleh micro frontend keranjang belanja), ia menerbitkan event bernama "cartItemAdded". Micro frontend daftar produk, yang berlangganan event ini, memperbarui jumlah keranjang yang ditampilkan tanpa langsung memanggil micro frontend keranjang belanja.
// Micro Frontend Keranjang Belanja (Penerbit):
function addItemToCart(item) {
// ... tambahkan item ke keranjang
publishEvent('cartItemAdded', { itemId: item.id });
}
function publishEvent(eventName, data) {
// ... terbitkan event menggunakan message broker atau event bus khusus
}
// Micro Frontend Daftar Produk (Pelanggan):
subscribeToEvent('cartItemAdded', (data) => {
// ... perbarui jumlah keranjang yang ditampilkan berdasarkan data event
});
function subscribeToEvent(eventName, callback) {
// ... berlangganan event menggunakan message broker atau event bus khusus
}
Kelebihan:
- Decoupling antara micro frontends.
- Fleksibilitas yang ditingkatkan.
- Skalabilitas yang ditingkatkan.
Kekurangan:
- Memerlukan implementasi message broker atau event bus.
- Bisa sulit untuk di-debug.
- Konsistensi eventual dapat menjadi tantangan.
3. Shared State:
Dalam pola ini, micro frontends berbagi status umum yang disimpan di lokasi pusat, seperti cookie browser, penyimpanan lokal, atau database bersama. Micro frontends dapat mengakses dan memodifikasi status bersama, memungkinkan mereka berkomunikasi satu sama lain secara tidak langsung. Pola ini berguna untuk berbagi sejumlah kecil data, tetapi dapat menyebabkan masalah kinerja dan inkonsistensi data jika tidak dikelola dengan benar. Pertimbangkan untuk menggunakan pustaka manajemen status seperti Redux atau Vuex untuk mengelola status bersama.
Contoh:
Micro frontends dapat berbagi token otentikasi pengguna yang disimpan dalam cookie. Setiap micro frontend dapat mengakses cookie untuk memverifikasi identitas pengguna tanpa perlu berkomunikasi langsung dengan layanan otentikasi.
// Menyetel token otentikasi (mis., di micro frontend otentikasi)
document.cookie = "authToken=your_auth_token; path=/";
// Mengakses token otentikasi (mis., di micro frontends lain)
function getAuthToken() {
const cookies = document.cookie.split(';');
for (let i = 0; i < cookies.length; i++) {
const cookie = cookies[i].trim();
if (cookie.startsWith('authToken=')) {
return cookie.substring('authToken='.length);
}
}
return null;
}
const authToken = getAuthToken();
if (authToken) {
// ... gunakan token auth untuk mengotentikasi pengguna
}
Kelebihan:
- Sederhana untuk diimplementasikan untuk sejumlah kecil data.
Kekurangan:
- Dapat menyebabkan masalah kinerja.
- Inkonsistensi data dapat terjadi.
- Sulit untuk mengelola perubahan status.
- Risiko keamanan jika tidak ditangani dengan hati-hati (mis., menyimpan data sensitif dalam cookie).
4. Window Events (Custom Events):
Micro frontends dapat berkomunikasi menggunakan custom events yang dikirim pada objek `window`. Ini memungkinkan micro frontends berinteraksi bahkan jika mereka dimuat dalam iframe atau web component yang berbeda. Ini adalah pendekatan native browser, tetapi memerlukan pengelolaan nama event dan format data yang cermat untuk menghindari konflik dan menjaga konsistensi.
Contoh:
// Micro Frontend A (Penerbit)
const event = new CustomEvent('custom-event', { detail: { message: 'Hello from Micro Frontend A' } });
window.dispatchEvent(event);
// Micro Frontend B (Pelanggan)
window.addEventListener('custom-event', (event) => {
console.log('Received event:', event.detail.message);
});
Kelebihan:
- Dukungan browser native.
- Relatif sederhana untuk diimplementasikan untuk komunikasi dasar.
Kekurangan:
- Namespace global dapat menyebabkan konflik.
- Sulit untuk mengelola struktur event yang kompleks.
- Skalabilitas terbatas untuk aplikasi besar.
- Memerlukan koordinasi yang cermat antara tim untuk menghindari tabrakan penamaan.
5. Module Federation (Webpack 5):
Module federation memungkinkan aplikasi JavaScript untuk memuat kode secara dinamis dari aplikasi lain saat runtime. Ini memungkinkan berbagi kode dan dependensi antara micro frontends yang berbeda tanpa perlu menerbitkan dan menggunakan paket npm. Ini adalah pendekatan yang ampuh untuk membangun frontends yang dapat dikomposisikan dan diperluas, tetapi memerlukan perencanaan dan konfigurasi yang cermat.
Contoh:
Micro Frontend A (Host) memuat komponen dari Micro Frontend B (Remote).
// Micro Frontend A (webpack.config.js)
const ModuleFederationPlugin = require('webpack/lib/container/ModuleFederationPlugin');
module.exports = {
// ... konfigurasi webpack lainnya
plugins: [
new ModuleFederationPlugin({
name: 'MicroFrontendA',
remotes: {
'MicroFrontendB': 'MicroFrontendB@http://localhost:3001/remoteEntry.js',
},
shared: ['react', 'react-dom'], // Bagikan dependensi untuk menghindari duplikat
}),
],
};
// Micro Frontend A (Component)
import React from 'react';
import RemoteComponent from 'MicroFrontendB/Component';
const App = () => {
return (
Micro Frontend A
);
};
export default App;
// Micro Frontend B (webpack.config.js)
const ModuleFederationPlugin = require('webpack/lib/container/ModuleFederationPlugin');
module.exports = {
// ... konfigurasi webpack lainnya
plugins: [
new ModuleFederationPlugin({
name: 'MicroFrontendB',
exposes: {
'./Component': './src/Component',
},
shared: ['react', 'react-dom'],
}),
],
};
// Micro Frontend B (src/Component.js)
import React from 'react';
const Component = () => {
return <h2>Hello from Micro Frontend B!</h2>;
};
export default Component;
Kelebihan:
- Berbagi dan menggunakan kembali kode tanpa paket npm.
- Pemuatan komponen dinamis saat runtime.
- Peningkatan waktu build dan efisiensi deployment.
Kekurangan:
- Memerlukan Webpack 5 atau yang lebih baru.
- Bisa kompleks untuk dikonfigurasi.
- Masalah kompatibilitas versi dengan dependensi bersama dapat muncul.
6. Web Components:
Web Components adalah sekumpulan standar web yang memungkinkan Anda membuat elemen HTML kustom yang dapat digunakan kembali dengan gaya dan perilaku yang dienkapsulasi. Mereka menyediakan cara agnostik platform untuk membangun micro frontends yang dapat diintegrasikan ke dalam aplikasi web apa pun, terlepas dari framework yang mendasarinya. Meskipun menawarkan enkapsulasi yang sangat baik, mereka mungkin memerlukan perkakas atau framework tambahan untuk menangani manajemen status atau skenario pengikatan data yang kompleks.
Contoh:
// Micro Frontend A (Web Component)
class MyCustomElement extends HTMLElement {
constructor() {
super();
this.attachShadow({ mode: 'open' }); // Shadow DOM yang dienkapsulasi
this.shadowRoot.innerHTML = `
<style>
:host {
display: block;
border: 1px solid black;
padding: 10px;
}
</style>
<p>Hello from Web Component!</p>
`;
}
}
customElements.define('my-custom-element', MyCustomElement);
// Menggunakan Web Component di halaman HTML mana pun
<my-custom-element></my-custom-element>
Kelebihan:
- Agnostik framework dan dapat digunakan kembali di berbagai aplikasi.
- Gaya dan perilaku yang dienkapsulasi.
- Teknologi web standar.
Kekurangan:
- Dapat menjadi verbose untuk ditulis tanpa pustaka pembantu.
- Mungkin memerlukan polyfills untuk browser yang lebih lama.
- Manajemen status dan pengikatan data dapat lebih kompleks dibandingkan dengan solusi berbasis framework.
Memilih Strategi yang Tepat
Strategi penemuan dan komunikasi layanan terbaik untuk arsitektur frontend microservice Anda bergantung pada beberapa faktor, termasuk:
- Ukuran dan kompleksitas aplikasi Anda. Untuk aplikasi yang lebih kecil, pendekatan sederhana seperti konfigurasi statis atau komunikasi langsung mungkin sudah cukup. Untuk aplikasi yang lebih besar dan lebih kompleks, pendekatan yang lebih kuat seperti registri layanan atau arsitektur berbasis event direkomendasikan.
- Tingkat otonomi yang dibutuhkan oleh tim Anda. Jika tim perlu sangat otonom, pola komunikasi yang longgar seperti events lebih disukai. Jika tim dapat berkoordinasi lebih dekat, pola yang lebih ketat seperti komunikasi langsung mungkin dapat diterima.
- Persyaratan kinerja aplikasi Anda. Beberapa pola komunikasi, seperti komunikasi langsung, dapat lebih berkinerja daripada yang lain, seperti events. Namun, manfaat kinerja dari komunikasi langsung dapat diimbangi oleh peningkatan kompleksitas dan coupling yang ketat.
- Infrastruktur Anda yang ada. Jika Anda sudah memiliki registri layanan atau message broker, masuk akal untuk memanfaatkan infrastruktur itu untuk frontend microservices Anda.
Praktik Terbaik
Berikut adalah beberapa praktik terbaik yang harus diikuti saat mengimplementasikan penemuan dan komunikasi layanan dalam arsitektur frontend microservice Anda:
- Buatlah tetap sederhana. Mulailah dengan pendekatan paling sederhana yang memenuhi kebutuhan Anda dan secara bertahap tingkatkan kompleksitas sesuai kebutuhan.
- Utamakan decoupling. Decoupling membuat aplikasi Anda lebih fleksibel, tangguh, dan lebih mudah dipelihara.
- Gunakan pola komunikasi yang konsisten. Menggunakan pola komunikasi yang konsisten di seluruh micro frontends Anda membuat aplikasi Anda lebih mudah dipahami dan di-debug.
- Pantau layanan Anda. Pantau kesehatan dan kinerja micro frontends Anda untuk memastikan bahwa mereka berfungsi dengan benar.
- Implementasikan penanganan kesalahan yang kuat. Tangani kesalahan dengan baik dan berikan pesan kesalahan informatif kepada pengguna.
- Dokumentasikan arsitektur Anda. Dokumentasikan pola penemuan dan komunikasi layanan yang digunakan dalam aplikasi Anda untuk membantu pengembang lain memahami dan memeliharanya.
Kesimpulan
Frontend microservices menawarkan manfaat signifikan dalam hal skalabilitas, kemampuan pemeliharaan, dan otonomi tim. Namun, mengimplementasikan arsitektur micro frontend yang sukses memerlukan pertimbangan yang cermat terhadap strategi penemuan dan komunikasi layanan. Dengan memilih pendekatan yang tepat dan mengikuti praktik terbaik, Anda dapat membangun frontend yang kuat dan fleksibel yang memenuhi kebutuhan pengguna dan tim pengembangan Anda.
Kunci keberhasilan implementasi micro frontends terletak pada pemahaman trade-off antara pola penemuan dan komunikasi layanan yang berbeda. Sementara konfigurasi statis menawarkan kesederhanaan, ia tidak memiliki dinamisme registri layanan. Komunikasi langsung mungkin tampak mudah tetapi dapat menyebabkan coupling yang ketat, sedangkan arsitektur berbasis event mempromosikan decoupling tetapi memperkenalkan kompleksitas dalam hal message brokering dan konsistensi eventual. Module federation menawarkan cara yang ampuh untuk berbagi kode tetapi memerlukan toolchain build modern. Demikian pula, web components menyediakan pendekatan standar, namun mereka mungkin perlu dilengkapi dengan framework saat mengelola status dan pengikatan data.
Pada akhirnya, pilihan optimal bergantung pada persyaratan spesifik proyek, keahlian tim, dan tujuan arsitektur keseluruhan. Strategi yang direncanakan dengan baik, dikombinasikan dengan kepatuhan pada praktik terbaik, dapat menghasilkan arsitektur micro frontend yang kuat dan terukur yang memberikan pengalaman pengguna yang unggul.