Microfronts di iframe
Di satu perusahaan, CTO membuat keputusan yang seimbang dan disengaja bahwa microfront harus setara dengan layanan mikro, dan harus disajikan di iframe.
Sebagai argumen, omong-omong, diberikan produk Office 360 ββdari Microsoft, sebelumnya menggunakan `<iframe />` untuk menu atas dan samping. Sekarang iframe tidak ada.
Alasan dan prasyarat untuk microfronts
Salah satu keuntungan utama dari ujung-ujung mikro adalah pembagian fungsionalitas monolit menjadi beberapa tim, kemampuan untuk melakukan pengujian ujung-ke-ujung secara lebih terperinci, dan juga mempermudah untuk menjual perangkat lunak dalam beberapa bagian (dalam kasus solusi kotak).
Semua aplikasi yang tersedia adalah React SPA. Mereka tidak memiliki kesamaan kecuali Material UI, React Router v4 dan embrio UI-kit sebagai modul npm.
Beberapa aplikasi akan digunakan dan dikirimkan dalam versi mandiri dan sebagai bagian dari aplikasi lain.
Microfront dibagi menjadi blok fungsional besar:
- Header aplikasi. Merutekan antar aplikasi
- Aplikasi dasbor. Dengan metrik dan widget. Setiap widget dasbor harus menjadi bagian dari aplikasi yang sesuai (terhubung melalui iframe).
- Aplikasinya sendiri. Beberapa dari mereka memasukkan bagian satu sama lain (tetapi tanpa fanatisme dan rekursi)
Dengan demikian, siklus pelepasan yang berbeda diperoleh, tidak bergantung satu sama lain. Selama aplikasinya mengikuti API internal.
Masalah # 0. Pemisahan mikrofront yang salah
Sayangnya, microfront belum dipikirkan secara mendalam. Contohnya adalah toko online. Tombol beli dan keranjang belanja dapat tersebar di banyak tempat, tetapi semuanya adalah satu mikrofront. Seperti produk kartu dalam 10 variasi, dan proses pemesanan (tempat tagihan dan alamat). Semua ini dapat menjadi bagian depan mikro terpisah dengan siklus rilisnya sendiri.
Pada kenyataannya, ternyata aplikasi dibagi dengan sangat kasar. Dalam analogi dengan toko online, ini adalah saat satu tim membuat keranjang dan halaman checkout, dan tim kedua mengerjakan sisanya (termasuk penghitung keranjang di semua halaman lainnya). Pada saat yang sama, semua orang menggunakan logika bisnis yang sama, dan antarmuka digunakan kembali pada level UI-kit, atau library Material-UI.
Ternyata aplikasi fungsional (ditandai dengan warna hijau dan ungu) memiliki banyak kesamaan. Bagian penting dari logika bisnis dalam dua aplikasi ini harus dipisahkan menjadi microfront terpisah dan digunakan. Sebenarnya, ada jauh dari dua aplikasi semacam itu. Secara total, ada sekitar tujuh aplikasi fungsional yang tidak menggunakan kembali logika pada level yang tepat.
Akibatnya, penghematan waktu untuk menggunakan kembali aplikasi gagal. Duplikasi fungsionalitas juga tetap pada level tinggi. Menggunakan ujung-tepi mikro tanpa iframe atau komponen dengan logika yang lebih kompleks dari kit UI yang diperluas dapat memecahkan masalah duplikasi fungsionalitas.
Masalah # 1. Kurangnya orkestrasi proses
Sementara banyak pertanyaan tentang organisasi layanan mikro dibahas. Bagaimana mereka akan berkomunikasi satu sama lain, dengan protokol apa, organisasi proses interaksi antara microfronted diletakkan di belakang burner.
Untuk menetralkan semua masalah CORS untuk selamanya, diputuskan untuk menanam nginx, yang akan menangani perutean. Jadi, setiap microfront dan setiap microservice memiliki alamatnya sendiri, misalnya: Pertanyaannya tetap, bagaimana cara menguji aplikasi selama mode pengembangan? Apakah setiap aplikasi akan disajikan di port yang berbeda?
https://domain.zone/dashboard
https://domain.zone/header
https://domain.zone/app1
https://domain.zone/app2
https://domain.zone/api1
https://domain.zone/api2
Di sinilah paket `http-proxy-middleware` hadir untuk menyelamatkan, yang dapat dikonfigurasi bersama dengan CRA. Ternyata hanya setengah dari pengembang front-end yang dapat mengatur pengaturan seperti itu. Tentu saja, seseorang tidak dapat menyalahkan siapa pun di sini, tetapi masalah seperti itu telah muncul, dan itu harus diselesaikan secara organisasi.
Versi yang jelas dari semua aplikasi dengan deskripsi fungsionalitas, metode yang tersedia, dan API internal juga diperlukan. Karenanya masalah berikutnya: dokumentasi.
Masalah # 2. Kurangnya API internal
Agar aplikasi dapat berinteraksi satu sama lain dengan sangat baik, diperlukan dokumentasi. Sayangnya, dalam kasus kami, hanya layanan mikro yang memiliki dokumentasi. Dan tatapannya tidak jatuh pada microfront.
Ini adalah bagian yang sangat penting dari sistem dalam kasus tim terdistribusi, dan bahkan dengan pergantian staf.
Diperlukan juga untuk mengembangkan mekanisme komunikasi antar aplikasi. Di sini, `postMessage API` hadir untuk menyelamatkan, atau akses langsung ke yang lain, dibangun di hampir setiap aplikasi React - Redux. Apa itu bus pesan? Tapi lebih dari itu nanti.
Masalah # 3. Iframe tidak cukup fleksibel
Tidak ada yang salah dengan menggunakan tag `<iframe />`. Ini adalah alat yang ampuh dengan bus pesan bawaan (API postMessage) dan penyesuaian keamanan ekstensif.
Namun, dalam kasus microfront, `<iframe />` memberlakukan banyak batasan. Salah satunya adalah ketidakmampuan untuk menggunakan kembali satu aplikasi di beberapa bagian halaman.
Gunakan kembali aplikasi
Dalam kasus analogi toko online, 10 tombol Beli akan membuat 10 `<iframe />`, yaitu 10 aplikasi React yang sedang berjalan. Memori tidak cukup untuk ini. Inilah salah satu alasan mengapa membagi aplikasi menjadi beberapa tim berdasarkan fitur tidak dimungkinkan.
URL tidak cocok sebagai manajemen negara
Kita semua terbiasa merutekan aplikasi melalui URL. Ini juga nyaman saat menggunakan microfront sebagai unit independen. Misalnya, jika bagian dari aplikasi utama cukup koheren untuk digunakan sendiri. Ini, tentu saja, bukan keuntungan unik dari pendekatan iframe, tetapi cukup mudah dilakukan.
Berikut adalah contoh bagaimana aplikasi ungu dari KDPV dengan URL berbeda dapat bekerja sebagai aplikasi mandiri:
Namun, ternyata tidak mungkin menggunakan antarmuka URL iframe untuk mengganti keadaan microfront dalam kasus kami: microfront mulai memuat dari awal karena integrasi yang tidak lengkap dari API riwayat dengan `pushState `dan Bereaksi Router - mendapatkan penuh halaman penyegaran.
Di luar penangan klik Κ»iframe`
Bayangkan Anda akan membuat menu dropdown. Seperti pada diagram di atas: dari menu pink. Dan juga menutupnya dengan mengklik ruang kosong. Dalam kasus iframe, Anda perlu menggunakan API postMessage bersyarat, karena klik keluar sama sekali tidak dikenali karena objek jendela yang berbeda. Atau buat retas dengan latar belakang transparan dari elemen iframe yang diperbesar dalam layar penuh.
Ngomong-ngomong, mengubah ukuran iframe dan menyesuaikan aplikasi induknya juga menjadi lebih rumit dan rumit.
Masalah Bonus: Penggunaan Cookie yang Tidak Pantas
Masalah ini tidak secara langsung terkait dengan microfront, tetapi membawanya ke tingkat kegilaan berikutnya.
Diputuskan untuk menulis di cookie otorisasi tidak hanya token, tetapi juga daftar lengkap hak atas bagian tertentu dari aplikasi. Semua ini dienkripsi oleh SHA - ??? dan diubah menjadi base64.
Akibatnya, ukuran cookie melebihi 8KB, yang merupakan nilai default untuk nodejs / nginx, (atau 2KB untuk ukuran satu catatan Cookie di Google Chrome), yang mengarah ke konfigurasi server yang lebih kompleks (tanpa mengeluarkan CRA, Anda tidak dapat memulai dengan pengaturan ini), dan juga untuk memisahkan kumpulan data terenkripsi yang besar ini menjadi string cookie yang lebih kecil.
Ini berarti bahwa setiap permintaan ke server, bahkan untuk mendapatkan `favicon.ico` atau untuk mendapatkan daftar bagian menu yang tersedia, dilengkapi dengan header tambahan dengan ukuran yang mengesankan.
Kesimpulan. Lalu bagaimana hidup dengan microfront?
Untuk memulainya, tentu saja, Anda perlu memutuskan apakah microfront diperlukan? Seringkali, UI-kit yang dikonfigurasi dan diperkaya dengan benar dalam bentuk modul npm memecahkan masalah rilis independen dan gaya visual yang sama.
- Jangan gunakan iframe. Ini tidak menyederhanakan pekerjaan, tetapi hanya menambah masalah kinerja, sangat membatasi kemampuan untuk membagi aplikasi menjadi microfront. Merender potongan SPA menjadi tag yang dipesan khusus adalah solusi yang jauh lebih efisien.
- Kembangkan orkestrasi proses: baik dalam produksi maupun untuk pengembangan. Tidak setiap pengembang ingin terjun ke industri terkait perutean dan proxy ketika dia dipekerjakan untuk memusatkan antarmuka dari blok yang sudah jadi.
- Kembangkan bus pesan antar aplikasi. Ini jauh lebih mudah dalam kasus ruang global tunggal, objek jendela.
- Buat dokumentasi tentang antarmuka untuk interaksi aplikasi, serta peluncuran dan konfigurasinya.