Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Membandingkan mikro-frontend dengan arsitektur alternatif

Seperti semua strategi arsitektur, keputusan untuk mengadopsi frontend mikro harus didasarkan pada kriteria evaluasi yang dipandu oleh prinsip-prinsip organisasi Anda. Micro-frontend memiliki kelebihan dan kekurangan. Jika organisasi Anda memutuskan untuk menggunakan frontend mikro, Anda harus memiliki strategi untuk mengatasi tantangan sistem terdistribusi

Saat memilih arsitektur aplikasi, alternatif paling populer untuk frontend mikro adalah monolit, aplikasi n-tier, dan layanan mikro dalam kombinasi dengan frontend aplikasi satu halaman (SPA). Ini semua adalah pendekatan yang valid, dan masing-masing memiliki kelebihan dan kekurangan.

Monolit

Aplikasi kecil yang tidak perlu sering diubah dapat dikirimkan dengan sangat cepat sebagai monolit. Bahkan dalam situasi di mana pertumbuhan yang signifikan diharapkan, monolit adalah langkah pertama yang alami. Kemudian, monolit dapat dipensiunkan atau difaktorkan ulang menjadi struktur yang lebih fleksibel. Dengan memulai dengan monolit, organisasi Anda dapat pergi ke pasar, mendapatkan umpan balik pelanggan, dan meningkatkan produk lebih cepat.

Namun, aplikasi monolitik cenderung terdegradasi jika tidak dipelihara dengan hati-hati atau karena basis kode tumbuh dalam ukuran dari waktu ke waktu. Ketika beberapa tim secara signifikan berkontribusi pada basis kode yang sama, mereka jarang berkontribusi pada pemeliharaan dan operasinya. Hal ini mengakibatkan ketidakseimbangan tanggung jawab, yang berdampak pada kecepatan dan menyebabkan inefisiensi. Pada saat yang sama, kopling yang tidak disengaja antara modul monolit menyebabkan efek samping yang tidak diinginkan saat basis kode berkembang. Efek samping tersebut dapat mengakibatkan malfungsi dan pemadaman.

Aplikasi N-tier

Aplikasi yang lebih kompleks yang memiliki kecepatan evolusi yang relatif statis dapat dibangun sebagai arsitektur tiga tingkat (presentasi, aplikasi, data), dengan lapisan REST atau GraphQL antara frontend dan backend. Ini jauh lebih fleksibel, dan tim untuk tingkatan yang berbeda dapat berkembang secara independen sampai batas tertentu. Kerugian dari aplikasi n-tier adalah jauh lebih sulit untuk menerapkan fungsionalitas. Frontend dan backend dipisahkan melalui kontrak API, jadi perubahan yang melanggar harus diterapkan bersama atau API harus dibuat versi.

Pertimbangkan skenario umum berikut: Jika merilis fitur baru memerlukan perubahan skema data, mungkin perlu berhari-hari bagi pemilik produk untuk menyetujui serangkaian fungsi dengan tim frontend. Kemudian tim frontend akan meminta tim backend untuk mengembangkan dan melepaskan fungsionalitas di pihak mereka. Tim backend akan bekerja dengan pemilik data untuk merilis pembaruan skema database. Selanjutnya, tim backend akan merilis versi baru API, sehingga tim frontend dapat mengembangkan dan merilis perubahan mereka. Dalam skenario ini, menyebarkan semua perubahan pada produksi mungkin memakan waktu berminggu-minggu atau bahkan berbulan-bulan, karena setiap tim memiliki backlog, prioritas, dan mekanisme sendiri seputar pengembangan, pengujian, dan pelepasan perubahan.

Layanan mikro

Dalam arsitektur microservices, backend didekomposisi menjadi layanan kecil, masing-masing menangani masalah bisnis tertentu dalam konteks terbatas. Setiap layanan mikro juga sangat dipisahkan dari layanan lain dengan mengekspos kontrak antarmuka yang jelas.

Perlu disebutkan bahwa konteks terbatas dan kontrak antarmuka juga harus ada dalam monolit yang dibuat dengan baik dan arsitektur n-tier. Namun, dalam arsitektur microservices, komunikasi terjadi melalui jaringan, biasanya protokol HTTP, dan layanan memiliki infrastruktur runtime khusus. Ini mendukung pengembangan independen, pengiriman, dan pengoperasian setiap layanan backend.

Memilih pendekatan untuk kebutuhan Anda

Monolit dan arsitektur n-tier menggabungkan beberapa masalah domain menjadi satu artefak teknis. Hal ini membuat aspek-aspek seperti dependensi dan aliran data internal mudah dikelola, tetapi membuat pengiriman fungsionalitas baru menjadi lebih sulit. Untuk mempertahankan basis kode yang koheren, tim sering menginvestasikan waktu dalam refactoring dan decoupling karena basis kode besar yang harus mereka tangani.

Aplikasi yang dikembangkan oleh beberapa tim mungkin tidak memerlukan kompleksitas tambahan yang datang dengan pindah ke frontend mikro. Ini terutama benar jika tim tidak membayar penalti kopling tinggi dan waktu tunggu yang lama untuk melepaskan perubahan.

Singkatnya, arsitektur yang lebih kompleks dan terdistribusi seringkali merupakan pilihan yang tepat untuk aplikasi yang kompleks dan bergerak cepat. Untuk aplikasi kecil hingga menengah, arsitektur terdistribusi tidak selalu lebih unggul dari yang monolitik, terutama jika aplikasi tidak akan berkembang secara dramatis dalam waktu singkat.