 |
| Apakah Frontend Bisa Di Desain Microservices Seperti Backend? |
Microservices adalah
cara populer untuk membangun tim kecil dan monolith yang dapat bekerja secara
mandiri. Pada dasarnya, microservices hanya berfungsi di backend.
Bahkan dengan arsitektur microservices terbaik, pengembangan frontend
masih memerlukan tingkat saling ketergantungan yang tinggi, dan ini
memperkenalkan sambungan dan overhead komunikasi yang dapat memperlambat
semua orang.
Sebelum memulai, yuk simak cerita di bawah
ini terlebih dahulu.
Pada suatu hari kamu ingin membeli kipas
angin baru. Namun, karena kesibukan yang tiada habisnya, kamu memutuskan untuk
membeli kipas tersebut secara daring melalui online shop favoritmu.
 |
| Sebuah monolit dapat didekomposisi dengan cara yang berbeda. Kita dapat membagi frontend dan backend atau menggunakan microservices di backend. Kami bahkan dapat membuat ulang frontend sebagai kumpulan komponen terisolasi yang dikelola oleh tim yang berbeda. |
Ketika membuka halaman utama online shop, kamu disuguhkan
dengan tampilan beranda yang menampilkan daftar kategori menu. Selanjutnya kamu
akan memilih kotak pencarian dan mencari “Kipas Angin”. Ketika menekan
tombol cari, kamu diarahkan ke halaman hasil pencarian.
Setelah proses pencarian, kamu pun
menemukan kipas yang diinginkan. Klik pada pilihan kipas tersebut dan melihat
detailnya di halaman detail. Lalu kamu juga akan menekan tombol “Beli”
dan diarahkan ke halaman pembayaran. Setelah membayar, anda diarahkan ke
halaman detail transaksi. Sekarang, hanya tinggal menunggu waktu hingga kipas
tersebut diantar ke rumah anda.
Dari cerita di atas, ternyata ada 6 fitur
yang sudah kamu akses, yaitu sebagai berikut.
·
Halaman beranda
·
Kotak pencarian
·
Halaman hasil pencarian
·
Halaman detail produk
·
Halaman pembayaran
·
Halaman detail transaksi
Umumnya, kita akan berpikir kalau aplikasi
adalah sebuah proyek besar yang terdiri dari banyak fitur. Jika Developer ingin
memodifikasi suatu fitur, misal fitur kotak pencarian, maka dia harus mengakses
seluruh fitur yang ada di dalam aplikasi online shop tersebut.
Itu tidak akan masalah dalam tim
kalau fiturnya hanya sedikit. Namun, berbeda jika ada fitur lain di
aplikasi tersebut, seperti fitur halaman toko, halaman kategori, dan halaman
promo. Tidak akan efisien apabila hanya satu tim saja yang mengerjakan semua
fitur tersebut. Idealnya, tim Developer akan
dibagi sesuai dengan fitur yang akan dikerjakan, misalnya tim toko, tim
produk, dan tim pembayaran.
Dengan struktur seperti itu, setiap tim
yang mengerjakan fiturnya mau tidak mau harus memakai satu proyek (dalam
istilah Developer yaitu source code) secara
bersamaan walaupun timnya berbeda-beda. Hal ini akan tidak efisien bukan?
Namun, bagaimana kalau ada cara lain
sehingga setiap tim cukup mengakses fitur yang dibutuhkan saja di tim tersebut
tanpa harus mengakses fitur tim lain?
Itulah tujuan dari Micro FrontEnd.
| Arsitektur Micro FrontEnd |
Bisakah kita mengambil pola arsitektur layanan mikro dan menerapkannya ke frontend? Ternyata kita bisa. Perusahaan seperti Netflix, Zalando, dan Capital One telah mendorong pola ini ke frontend, meletakkan dasar untuk microfrontends.
Sebuah monolith dapat didekomposisi dengan cara yang
berbeda. Kita dapat membagi frontend dan backend atau menggunakan
layanan mikro di backend. Kami bahkan dapat membuat ulang frontend
sebagai kumpulan komponen terisolasi yang dikelola oleh tim yang berbeda.
Dengan microfrontend, tidak ada satu tim pun yang memiliki
UI secara keseluruhan. Sebaliknya, setiap tim memiliki bagian layar, halaman,
atau konten. Fungsionalitas frontend dikelola oleh tim yang berbeda,
disebarkan secara independen, dan disuntikkan ke beranda secara
transparan kepada pengguna akhir.
Manfaat dan tantangan microfrontends
Microfrontends menawarkan manfaat serupa
dengan layanan mikro. Yaitu, kami dapat meningkatkan pengembangan dengan memecah
kode frontend menjadi bagian-bagian yang terisolasi, yang menjadi tanggung
jawab tim yang berbeda. Seperti halnya layanan mikro, setiap fitur dapat
dirilis sendiri, kapan saja, dengan sedikit koordinasi. Ini mengarah ke
pembaruan yang lebih sering.
Tim vertical
Microfrontends
memungkinkan pembuatan tim vertikal, yang berarti tim pengembang yang
lengkap dapat memiliki fitur di backend dan frontend secara
bersamaan.
Komponen yang dapat digunakan secara terus
menerus
Setiap bagian dari microfrontend adalah unit
yang dapat digunakan. Hal ini memungkinkan tim untuk memublikasikan
perubahan mereka tanpa menunggu rilis atau bergantung pada tim lain yang
menyelesaikan pekerjaan mereka. Hasil akhirnya adalah bahwa frontend
dapat diperbarui beberapa kali per hari.
Tantangan desain microfrontend
Tantangan utama microfrontends adalah menciptakan
klien yang cepat dan responsif. Kita tidak boleh melupakan fakta bahwa frontend
hidup di lingkungan dengan memori, CPU, dan jaringan yang terbatas, atau kita
berisiko berakhir dengan UI yang lambat.
UI yang tajam sangat penting untuk keberhasilan
produk. Sebuah survei baru-baru ini menunjukkan bahwa “situs yang dimuat
dalam 1 detik memiliki tingkat konversi 3x lebih tinggi daripada situs yang
dimuat dalam 5 detik”. Setiap detik pengguna harus menunggu, uang dilempar
keluar jendela.
Selain semua tantangan yang dimiliki layanan
mikro, desain microfrontend menimbulkan beberapa masalah lagi:
Isolasi: kode setiap tim pada
akhirnya harus ada di browser yang sama. Kita harus berhati-hati dalam
mengisolasi modul yang terpisah untuk menghindari tabrakan kode atau gaya.
Sumber daya bersama: untuk menghindari duplikasi dan menjaga agar frontend tetap
tipis, komponen harus berbagi aset dan pustaka jika memungkinkan, yang dapat
membuat sambungan yang tidak diinginkan.
Aksesibilitas:
ketergantungan yang tinggi pada JavaScript untuk merender halaman berdampak
negatif pada aksesibilitas.
Penataan: Ketika UI terdiri dari
komponen yang diproduksi oleh berbagai tim, mempertahankan tampilan yang
konsisten lebih rumit. Inkonsistensi gaya kecil bisa terasa menggelegar.
Koordinasi: dengan
begitu banyak bagian yang bergerak, API harus didefinisikan dengan sangat baik
dan stabil. Tim harus berkoordinasi tentang bagaimana komponen yang berbeda di
microfrontend berkomunikasi satu sama lain dan layanan microend backend.
Prinsip-prinsip untuk membangun microfrontends
Ada dua metode pelengkap untuk merender UI
terpadu dari komponen microfrontend yang terpisah: rendering sisi server
dan sisi klien.
Render sisi server (SSR)
Render sisi server menawarkan kinerja yang lebih
cepat dan konten yang lebih mudah diakses. Rendering di server adalah
alternatif yang baik untuk menyajikan konten dengan cepat — terutama pada
perangkat berdaya rendah seperti ponsel kelas bawah. Ini juga merupakan mode
mundur yang sesuai ketika JavaScript dinonaktifkan.
 |
| Server web mengumpulkan halaman penuh dari konten yang disediakan oleh layanan mikro yang berbeda. Ini berfungsi sebagai halaman konten pertama. Hidrasi kemudian dapat digunakan untuk menambahkan konten yang lebih dinamis. |
Kami memiliki beberapa cara untuk melakukan SSR:
Server Side Include (SSI): adalah bahasa scripting sederhana yang dijalankan oleh server
web. Bahasa menggunakan arahan untuk membangun fragmen HTML menjadi satu
halaman penuh. Fragmen ini mungkin berasal dari file lain atau tanggapan
program. SSI didukung oleh semua server web utama, termasuk Apache, Nginx,
dan IIS.
iframes: fitur iframe yang
terhormat memungkinkan kita untuk menyematkan konten HTML sewenang-wenang pada
halaman.
Edge Side Includes (ESI): alternatif yang lebih modern untuk SSI. ESI dapat menangani
variabel, memiliki kondisi, dan mendukung penanganan kesalahan yang lebih baik.
ESI didukung oleh caching server HTTP seperti Varnish.
Jadi, misalnya, kita dapat menggunakan SSI untuk
merender halaman dari HTML dengan ini:
Kata kunci virtual membuat server web meminta
konten dari URL atau program CGI. Dalam kasus kami, kami
perlu menyiapkan server web untuk menanggapi permintaan berdasarkan jalur
/hello-world dengan fragmen yang sesuai:
SSR digunakan di banyak kerangka kerja web untuk
membuat layar pertama. Selain itu, ada juga beberapa utilitas khusus SSR yang
menarik seperti compoxure, nodesi, dan tailor.
Render sisi klien (CSR)
Render sisi klien membangun halaman di browser
pengguna dengan mengambil data dari layanan mikro dan memanipulasi DOM.
Sebagian besar kerangka kerja web menggunakan beberapa bentuk CSR untuk
meningkatkan pengalaman pengguna.
 |
| CSR secara dinamis merender halaman di browser pengguna menggunakan data yang disediakan oleh titik akhir. |
Alat utama yang kita miliki untuk menulis
komponen yang digabungkan secara longgar adalah Custom Elements. Custom
Elements adalah bagian dari standar HTML. Mereka memungkinkan kita untuk
membuat tag HTML baru dan melampirkan logika dan perilaku ke tag tersebut.
Elemen khusus dipasang dan dilepas secara
dinamis dari halaman menggunakan JavaScript:
Sementara sebagian besar kerangka kerja frontend
dapat digunakan untuk mikrofrontend, beberapa telah dirancang khusus untuk
mereka:
Piral: mengimplementasikan
komponen terisolasi yang disebut pilet. Pilet adalah modul yang
menggabungkan konten dan perilaku.
Hesitant: kerangka kerja. Ini
memungkinkan kita untuk menyematkan kode yang ditulis dalam kerangka kerja apa
pun sebagai widget.
Single SPA:
meta-framework untuk menyatukan UI menggunakan kombinasi kerangka kerja
frontend seperti React, Angular, dan Ember, antara lain.
Frint: kerangka kerja modular
lain untuk membangun aplikasi berbasis komponen. Terintegrasi dengan React,
Vue, dan Preact.
WebPack Module Federation: plugin WebPack untuk membuat Aplikasi Halaman Tunggal (SPA)
dengan menggabungkan build terpisah. Bangunan ini dapat dikembangkan secara
independen dari masing-masing
Kesimpulan
Beralih ke arsitektur microfrontend dapat
memberi tim pengembangan kami lebih banyak otonomi, sehingga mempercepat
pengembangan. Namun, peringatan yang sama yang berlaku untuk microservices
juga relevan untuk mikrofrontend. Kita perlu memiliki desain yang
terbukti, yang berarti microfrontends tidak cocok untuk proyek
greenfield.
Posting Komentar