Kode redundant dikirim ke pipa dengan Micro-frontends


12

Pemahaman saya tentang Micro-frontends adalah bahwa masalah utama yang mereka selesaikan adalah dalam membantu perusahaan memiliki banyak tim yang berbeda, bekerja pada komponen individu / aplikasi kecil yang akan digunakan untuk menyusun aplikasi web yang besar.

Di sini masalah utama yang dipecahkan adalah kemampuan beberapa tim untuk bekerja secara mandiri dan masih dapat membangun komposit besar. Masalahnya BUKAN tentang memiliki bundel rilis ramping untuk pengguna akhir . Apakah pemahaman itu benar?

Benarkah jika kita memiliki beberapa aplikasi kecil yang digunakan untuk membuat aplikasi web besar, kita bisa berpotensi memiliki beberapa aplikasi kecil yang mengirimkan pustaka Javascript yang sama ( seperti Lodash ) ke peramban pengguna akhir sebagai bagian dari aplikasi mereka. bundel vendor individual yang mengarah ke sejumlah kode duplikat / redundan yang dikirim ke pengguna?

Bukankah ini masalah yang harus kita khawatirkan saat merancang aplikasi front-end?


2
Saya pikir ini benar - benar masalah yang perlu Anda pertanggungjawabkan. Sayangnya, saya tidak tahu bagaimana keadaan orang tentang hal ini. Pertanyaan bagus!
RubberDuck

Jawaban:


12

Anda sepenuhnya benar bahwa ada tradeoff yang terlibat di sini: Anda berdagang di beberapa aspek pengalaman pengguna untuk mendapatkan pengalaman pengembang yang lebih baik (yang pada gilirannya dapat meningkatkan pengalaman pengguna dengan cara yang berbeda). Apakah ini sepadan? Tergantung.

Misalnya saya pikir Spotify menggunakan pendekatan ini untuk membagi UI mereka menjadi komponen yang terisolasi ( sumber ). Setiap widget hidup dalam iframe dan karena itu dapat memiliki set perpustakaan sendiri dll. Mereka memiliki kendala organisasi yang unik bahwa pekerjaan dilakukan oleh regu otonom (tim lintas fungsi). Ini membuatnya lebih sulit untuk menyepakati standar seluruh perusahaan dan kemudian mengubah standar-standar ini. Jadi bagi mereka, mikro-frontend membantu menjaga fleksibilitas. Tetapi tanpa pendekatan ini, mungkin aplikasi desktop mereka akan kurang dari memory hog.

Caching HTTP tidak akan banyak membantu: setiap micro-frontend mungkin menggunakan versi kerangka kerja yang berbeda . Selain itu, biaya duplikasi tidak hanya transfer data, tetapi biaya sisi klien dari (kembali) mengkompilasi perpustakaan dan menyimpan struktur data yang digandakan.

Secara pribadi, saya pikir mikro-frontend seperti itu bisa menjadi arsitektur yang valid tetapi mungkin tidak disarankan kecuali

  • Anda adalah organisasi yang sangat besar dengan tim yang sangat otonom yang semuanya bekerja pada antarmuka pengguna dan perlu melakukan rilis yang sangat sering (misalnya setiap hari) dan
  • anggaran kinerja UX Anda memiliki ruang untuk duplikasi ini, atau produk Anda sangat bagus sehingga UX tidak masalah. Perhatikan bahwa kinerja harus diuji pada perangkat kelas bawah, bukan pada mesin pengembangan Anda.

Jika organisasi Anda tidak besar atau jika tim Anda sedikit lebih terspesialisasi, mungkin akan lebih mudah bagi semua orang yang terlibat (manajemen, pengembang, dan akhirnya pengguna) untuk memiliki proses membangun dan penyebaran bersama yang menghindari duplikasi yang tidak perlu. Misalnya, jika Anda hanya memiliki 4 tim yang bekerja pada UI, mereka mungkin dapat berbicara satu sama lain untuk menyetujui satu set perpustakaan umum, dan bagaimana mengintegrasikan pekerjaan mereka ke dalam arsitektur yang kohesif.

Micro-frontends tampaknya menjadi salah satu dari hal-hal ini yang benar-benar keren tetapi Anda tidak perlu sampai Anda beroperasi pada skala.


3
Saya pikir memilih versi kerangka tunggal di seluruh aplikasi Anda mungkin sepadan dengan usaha.
Robert Harvey
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.