Smashing Podcast Episode 6 Dengan Luca Mezzalira: Apa Itu Micro-Frontends?

Kami mengakhiri tahun ini dengan podcast Smashing lainnya! Kali ini, kita akan berbicara tentang mikro-frontend. Apa itu mikro-frontend? Apa bedanya dengan pendekatan yang mungkin kita ambil saat ini? Mari kita cari tahu dari pelopor mikro-frontend, Luca Mezzalira.

Tampilkan Catatan

Update mingguan

• “Menambahkan Fungsi Dinamis Dan Asinkron Ke Situs JAMstack,” Jason Lengstorf
• “Alat Data Kuantitatif Untuk Desainer UX,” Adonis Raduca
• “Membuat Keterampilan Suara Untuk Asisten Google dan Amazon Alexa,” Tris Tolliday
• “Beyond Sprint 0: Sebuah Alternatif Untuk Mengintegrasikan Tim,” Shamsi Brinn
• “Membantu Peramban Mengoptimalkan Dengan Properti Berisi CSS,” Rachel Andrew

Mikro-Frontend

• Situs web Luca Mezzalira
• Luca di Twitter
• “Micro-Frontends, Masa Depan Arsitektur Frontend” di Medium
• Lebih banyak tulisan Luca tentang mikro-frontend dapat ditemukan di akun Medium-nya
• Buku Luca "Arsitektur Reaktif Front-End"

Salinan

Drew McLellan: Dia adalah pakar pengembang Google di teknologi web dan manajer komunitas JavaScript London. Dengan pengalaman lebih dari 15 tahun, saat ini ia bekerja sebagai Wakil Presiden Arsitektur, merancang platform video olahraga DAZN, yang menghadirkan konten olahraga sesuai permintaan kepada jutaan pengguna yang semuanya menonton langsung. Dia adalah penulis buku Front-End Reactive Architectures for Apress dan juga peninjau teknis untuk Apress, Packt Publishing, Pragmatic Bookshelf, dan O'Reilly, serta menjadi pembicara publik berpengalaman di konferensi teknis di seluruh dunia. Dia orang Italia, berjenggot tampan, dan jelas memiliki pengetahuan mendalam tentang platform web. Tapi tahukah Anda bahwa dia pernah melintasi Amerika Selatan dengan seekor burung unta? Teman-temanku yang hebat, tolong sambut Luca Mezzalira. Hai, Luca. Apa kabar?

Luca Mezzalira: Saya hebat.

Drew: Saya ingin berbicara dengan Anda hari ini tentang masalah mikro-frontend. Sekarang ini adalah konsep yang benar-benar baru bagi saya, tentu dari namanya, dan saya berharap ini juga baru bagi banyak pendengar kita. Sebelum kita masuk ke mikro-frontend sendiri, saya kira kita harus memahami masalah yang ingin Anda atasi dengan mereka. Jadi mungkin Anda bisa memberi tahu kami sedikit tentang bagaimana Anda melihat aplikasi dengan cara yang lebih tradisional dan masalah seperti apa yang dihadapi hal-hal itu yang mungkin menjadi solusi mikro-frontend?

Luca: Oke, itu titik awal yang bagus, menurut saya. Jadi biasanya ketika Anda mengimplementasikan atau mendesain proyek lapangan hijau baru dan Anda ingin bekerja dengan aplikasi ujung depan, Anda memiliki beberapa arsitektur yang dapat Anda manfaatkan. Anda dapat menggunakan aplikasi satu halaman, Anda dapat menggunakan aplikasi rendering sisi server, atau Anda dapat menggunakan aplikasi multi-halaman yang dibuat hanya dengan halaman HTML sederhana. Jelas itu adalah opsi yang sangat valid dan saya pikir sangat digunakan oleh banyak pengembang. Masalah sebenarnya yang kami coba pecahkan di sini adalah bagaimana Anda dapat menskalakan konsep-konsep ini dengan tim terdistribusi ke ratusan pengembang yang bekerja pada basis kode yang sama, karena kenyataannya adalah ketika Anda bekerja di platform ini khususnya, ketika Anda memikirkan tentang Platform SaaS misalnya, Anda harus memiliki banyak pengembang dan beberapa tim yang mengerjakan proyek yang sama. Dan tentu saja cara, misalnya, Anda melakukan akuisisi atau retensi benar-benar berbeda dalam cara Anda mengekspos katalog atau bagaimana Anda menunjukkan bagian tertentu dari sebuah platform.

Luca: Jadi sekarang dalam pengalaman saya, saya banyak bekerja dengan aplikasi satu halaman. Saya bekerja dengan aplikasi rendering sisi server, tetapi di beberapa titik di DAZN saya akan diminta untuk memikirkan cara untuk menskalakan tim teknis kami. Dan saya perlu muncul ... jika untuk backend kami memiliki beberapa solusi yang merupakan layanan mikro dalam hal ini, sehingga kami dapat menskalakan API kami secara mandiri, dan mempertimbangkan skala dan volume untuk throughput tertentu pada API tertentu. Di ujung depan, sungguh, itu benar-benar lebih sulit karena jika Anda memikirkannya, Anda tidak memiliki masalah teknis untuk dipecahkan ketika Anda perlu menskalakan, jika Anda menggunakan aplikasi satu halaman, misalnya. Mungkin untuk rendering sisi server Anda memiliki beberapa, tetapi pada aplikasi satu halaman, misalnya, itu didistribusikan secara alami karena ada di sisi klien, sisi klien yang berbeda.

Luca: Jadi satu-satunya yang mereka muat hanyalah beberapa file statis seperti CSS dan HTML dan JavaScript yang disajikan oleh CDN, dan dalam hal ini Anda dapat menyesuaikan skalanya, itu bukan tantangan besar. Namun tantangan sebenarnya adalah bagaimana Anda menskalakan tim yang bekerja pada platform yang sama, karena terkadang tantangan yang dihadapi oleh satu tim bisa sangat berbeda dengan tantangan yang dihadapi tim lain, dan biasanya yang Anda lakukan adalah mencoba mencari banyak tradeoff antara hal-hal. Karena jika Anda berpikir, mari kita coba memikirkan kasus penggunaan yang normal. Jadi biasanya ketika Anda memulai sebuah platform, Anda memulai dari yang kecil. Jadi Anda mencoba membuat aplikasi satu halaman cepat itu, juga Anda memiliki monolit, jadi Anda hanya mengatur semuanya di CICD Anda sekali saja untuk ujung depan dan ujung belakang, dan kemudian Anda mulai mengulangi logika Anda. Tetapi kenyataannya adalah ketika Anda sukses, Anda perlu mengembangkan bagian ini, dan tidak selalu mempertahankan arsitektur yang sama yang dapat, katakanlah, menciptakan keuntungan bagi bisnis Anda, karena mungkin Anda dapat menemukan beberapa hambatan.

Luca: Jadi sekarang kembali ke bagian aplikasi satu halaman. Jadi jika kami ingin menskalakan bagian aplikasi satu halaman, tantangannya bukan teknis, tetapi dengan manusia jika Anda mau. Jadi bagaimana kami dapat menskalakan tim yang mengerjakan aplikasi yang sama. Jadi apa yang saya lakukan beberapa tahun yang lalu adalah, adalah mulai melihat kemungkinan arsitektur dan prinsip-prinsip yang memungkinkan saya untuk menskalakan ujung depan serta ujung belakang. Jadi kerjakan prinsip-prinsip backend sehingga Anda dapat menemukan layanan mikro. Saya mulai melihat solusi yang berbeda dan mereka keluar dengan mikro-frontend yang pada awalnya kami bahkan tidak menyebutnya seperti itu karena jelas selama bertahun-tahun yang lalu tidak ada, katakanlah, nama itu untuk arsitektur tertentu .

Luca: Tapi kenyataannya adalah mengambil monolit, jadi aplikasi satu halaman dan mengirisnya dengan cara yang memungkinkan kita untuk memfokuskan diri pada masalah kecil. Jadi masalah yang lebih kecil dari seluruh aplikasi dan mencoba menyelesaikannya dengan cara terbaik. Secara teknis. Jelas itu mengarah untuk memiliki bagian independen dari aplikasi frontend Anda yang dapat digunakan dalam produksi tanpa memengaruhi yang lainnya. Jadi tantangan pada dasarnya untuk Micro-frontend adalah mencoba mencari cara untuk mengambil aplikasi satu halaman atau aplikasi yang dirender sisi server dan membuat artefak ini, katakanlah, sedekat mungkin dengan domain bisnis, dan dapat digunakan secara mandiri .

Drew: Jadi maksud saya Anda menyebutkan layanan mikro di bagian belakang. Jadi secara konseptual ini adalah sejenis solusi untuk masalah tersebut. Layanan mikro melayani di ujung belakang, tetapi porting ke ujung depan. Apakah itu kesetaraan kasar atau lebih terlibat di dalamnya?

Luca: Ya. Tidak, ini adalah cara untuk memecahkan masalah yang sama dengan mencoba memecahkan layanan mikro di bagian belakang tetapi di bagian depan saat ini. Biasanya ketika saya memulai perjalanan ini di awal, Anda tahu, Anda mulai memikirkannya dan Anda mulai mengevaluasi pendekatan yang berbeda. Dan dalam beberapa bulan terakhir saya menemukan apa yang mereka sebut, kerangka kerja keputusan Micro-frontend yang pada dasarnya adalah empat langkah yang mereka gunakan untuk, katakanlah Anda mengidentifikasi pendekatan untuk Micro-frontend, karena jika sampai sekarang, kami biasanya memilih satu kerangka kerja yang merancang arsitektur untuk kami dan kami menerapkan di atas arsitektur mereka. Jika Anda berpikir tentang sudut atau berpikir tentang Bereaksi atau Redux. Anda memiliki semua bagian yang dibutuhkan tetapi Anda tidak mengambil keputusan arsitektural. Anda akan mengambil keputusan desain atau bagaimana Anda menerapkannya di atas arsitektur spesifik itu.

Luca: Jadi di Micro-frontend Anda harus memulai langkah mundur. Jadi kita perlu memikirkan bagaimana kita ingin mengiris aplikasi kita terlebih dahulu. Jadi biasanya ada dua opsi untuk itu. Anda dapat mengiris secara horizontal, sehingga Anda dapat memiliki beberapa mikro-frontend dalam tampilan yang sama atau Anda dapat mengiris secara vertikal. Oleh karena itu Anda selalu memuat satu Micro-frontend per waktu. Dan keputusan itu cukup penting karena kemudian akan mengalirkan opsi lain tertentu yang Anda miliki berdasarkan keputusan awal yang dibuat. Jadi yang pertama, seperti yang saya katakan, Anda memutuskan bagaimana Anda ingin mengiris aplikasi Anda. Yang kedua adalah bagaimana Anda ingin menyusun aplikasi Anda. Jadi, Anda ingin memiliki, misalnya, shell aplikasi yang memuat satu atau beberapa mikro-frontend dalam tampilan yang sama. Anda ingin memiliki, saya tidak tahu, server aplikasi yang menyusun fragmen berbeda dari aplikasi Anda, begitu berbeda Micro-frontend dan kemudian menyajikan tampilan akhir kepada pengguna Anda. Atau Anda ingin menggunakan edge-side yang disertakan, ini adalah standar yang ada di dalam CDN untuk membuat halaman dan menyajikannya di sana.

Luca: Itu adalah tiga dari pilihan yang kamu miliki. Dan kemudian selain menulis, Anda perlu memikirkan bagaimana Anda ingin merutekan. Jadi bagaimana Anda merutekan, saya tidak tahu, /login atau /signin ke bagian katalog atau objek detail tertentu. Juga di sini Anda memiliki tiga opsi. Anda dapat melakukannya di server aplikasi, Anda dapat melakukannya di level CDN dengan Lambda Edge atau pekerja web lainnya di CloudFlare atau yang lainnya. Atau Anda dapat melakukan situs klien. Jadi, Anda memiliki logika di dalam shell aplikasi yang Anda katakan, oke, sekarang untuk URL khusus ini Anda perlu memuat tampilan lain atau mikro-frontend lainnya. Dan yang terakhir adalah bagaimana Anda berkomunikasi dengan Micro-frontend.

Luca: Jadi biasanya jika Anda menyukai beberapa Micro-frontend pada halaman yang sama, ada kerumitan yang lebih tinggi dalam mengelola komunikasi ini, karena Anda perlu mempertahankan Micro-frontend independen yang berbeda. Jadi itu berarti Anda tidak dapat memiliki referensi tentang bagaimana halaman tersebut disusun. Jadi biasanya Anda dapat menggunakan hal-hal seperti acara khusus atau pengukur acara yang disuntikkan di dalam setiap mikro-frontend tunggal. Dan kemudian Micro-frontend berkomunikasi bersama. Jelas dalam kasus lain ketika Anda memiliki seperti katakanlah pemisahan vertikal Micro-frontend Anda jauh lebih mudah, karena di dalam vertikal pada dasarnya representasi vertikal Micro-frontend adalah aplikasi satu halaman atau satu halaman. Dan dalam hal ini lebih mudah untuk katakanlah membuat dan berbagi memiliki status bersama di seluruh Micro-frontend.

Luca: Kemudian jika Anda berpikir untuk memiliki beberapa Micro-frontend secara bersamaan, maka Anda harus menghindari status yang dibagikan di seluruh Micro-frontend, karena jika tidak, Anda menggabungkan berbagai hal. Alih-alih seluruh konsep di sini adalah decoupling dan memiliki penyebaran independen. Dan oleh karena itu, katakanlah tantangan pemisahan horizontal, yang merupakan keputusan pertama yang harus Anda ambil atau pemisahan vertikal, benar-benar berbeda, dan kita harus sangat menyadari mana yang sesuai dengan kasus penggunaan kita.

Drew: Jadi, alih-alih solusi teknis tertentu, antarmuka mikro sangat mirip dengan pola desain yang akan Anda terapkan dalam teknologi apa pun yang sesuai untuk masalah tertentu yang Anda coba selesaikan?

Luca: Ya, lebih dari teknologi, saya akan melihat bahwa kami memilih arsitektur yang tepat untuk pekerjaan yang tepat. Sekedar memberikan contoh, saya sedang berbicara ... ada kerangka kerja yang terkenal, yang cukup baru untuk Micro-frontend, itu disebut kerangka Luigi, yang dirilis oleh SAP open source. Apa yang mereka lakukan adalah membuat beberapa iframe di mana mereka membungkus Micro-frontend mereka di dalamnya. Jadi sekarang kalau dipikir-pikir, misalkan saja, menggunakan iframe saat ini, Anda berada di situs publik yang mungkin karena SEO atau fitur lain yang wajib, bisa jadi bermasalah.

Luca: Tetapi dalam kasus SAP, jika Anda memikirkannya, mereka memiliki aplikasi perusahaan seperti di mana mereka dapat mengontrol browser yang digunakan pengguna, mereka dapat mengontrol lingkungan, mereka tidak perlu tersedia di banyak atau versi browser yang berbeda. Jadi bagi mereka hal ini memungkinkan mereka untuk memiliki area aplikasi tertentu yang konstan dan mereka memiliki area tertentu yang berubah secara independen tanpa masalah. Tetapi jelas solusi iframe tidak akan berfungsi dalam situasi lain. Sebagai contoh lain, Spotify, kami menggunakan iframe di awal. Bahkan publikasi meja masih terdiri dari beberapa iframe dan setiap iframe tunggal adalah aplikasi kecil yang, saya tidak tahu, hanya pemutar musik atau hanya rekomendasi mereka, apa pun itu. Mereka mencoba untuk memiliki pendekatan yang sama di web, tetapi mereka menolaknya tahun ini untuk kembali ke aplikasi satu halaman.

Luca: Dan itu berarti, mereka menjelaskan mengapa di blog teknis, mereka mengatakan bahwa jelas jika Anda menerapkannya pada jutaan pengguna yang menggunakan iframe yang perlu memuat setiap kali file vendor yang sama. Dan kemudian Anda memiliki banyak dependensi yang digandakan dan waktu untuk berinteraksi dengan halaman Anda akan lebih lama. Jadi pada kenyataannya, pendekatan ini bisa cocok untuk kasus penggunaan tertentu, tetapi seharusnya tidak cocok untuk semuanya. Itu sebabnya saya mengatakan, seperti yang saya jelaskan sebelumnya, jika Anda memiliki kerangka kerja keputusan yang membantu Anda mengatasi hal itu dan Anda dapat mulai mengatakan, oke, saya memotong aplikasi dengan cara ini, oleh karena itu saya memiliki opsi yang tersedia ketika saya ingin menulis, ketika saya ingin mengarahkan, ketika saya ingin berkomunikasi, itu harus membimbing Anda untuk memiliki keputusan yang tepat pada waktu yang tepat.

Luca: Kemudian jelas selain dari empat keputusan itu, ada banyak keputusan lainnya. Seperti bagaimana Anda menciptakan konsistensi dalam sistem desain yang Anda miliki di semua Micro-frontend. Atau saya tidak tahu bagaimana Anda mengelola dependensi dan menghindari bentrokan ketergantungan di dalam Micro-frontend, tetapi kenyataannya adalah empat keputusan yang saya sebutkan sebelumnya akan memungkinkan Anda untuk mengambil semua yang lain dengan cepat tanpa harus masalah overthinking, yang merupakan solusi terbaik karena Anda sudah menetapkan landasan, empat pilar, yang akan memungkinkan Anda untuk mengambil semua keputusan lain ... Saya tidak mengatakan dengan cara yang mudah, tetapi dengan cara yang lebih cepat daripada review atau spektrum peluang.

Drew: Anda sebutkan sebelumnya, cara Micro-frontend dapat membantu dengan jenis struktur tim dalam organisasi Anda dan memiliki banyak orang yang mengerjakan aplikasi yang sama. Apa implikasinya dan apakah ada bedanya jika tim Anda didistribusikan atau ditempatkan bersama atau apakah ada tantangan yang dihadapi di sana?

Luca: Ya. Jadi saya bisa memberi tahu Anda apa cerita DAZN. Itu adalah perusahaan tempat saya bekerja. Saat ini di DAZN, kami memiliki tantangan yang menyenangkan. Jadi saat ini kami memiliki lebih dari 300 orang yang bekerja di bagian depan dan belakang platform kami. Ini adalah platform OTT yang streaming langsung di acara olahraga secara global. Dan yang menarik adalah jika semua layanan mikro kami tahu cara mengelolanya kurang lebih dan kami telah mendistribusikan tim. Jadi kami memiliki empat pusat pengembangan. Kami ingin menempatkan tim di setiap pusat pengembangan di depan, dan kami mencoba pendekatan ini dan itu bekerja dengan cukup baik. Jadi dengan Micro-frontend kami dapat menyediakan domain bisnis yang berbeda di lokasi yang berbeda dan memungkinkan komunikasi silang antara tim di dalam domain bisnis tertentu, karena skenario terburuk di sana adalah jika Anda harus berbicara dengan tim lain di domain bisnis yang sama. , Anda hanya mencapai jarak berjalan kaki dari meja Anda. Jika sebaliknya Anda perlu mendiskusikan hal tertentu di tim distributif, jadi dengan mungkin seseorang di London alih-alih Amsterdam, atau alih-alih perusahaan di Polandia, Anda cukup mengatur panggilan.

Luca: Tapi komunikasi seperti itu lebih jarang terjadi daripada komunikasi yang terjadi antar tim di dalam lokasi yang sama. Dan itulah mengapa kami mulai mengerjakannya. Jadi hal pertama yang mereka lakukan adalah melihat bagaimana pengguna kami berinteraksi dengan situs web kami, bagaimana perusahaan itu terstruktur. Dan ketika kami mengidentifikasi empat area utama yang sedang kami kerjakan, yang saat ini adalah akuisisi dan retensi, katakanlah porting aplikasi inti mereka di beberapa TV dan seluler dan memiliki domain inti yang bagi kami adalah pemutar video dan fase penemuan konten kami. Dan akhirnya semua elemen back office. Saya dapat mengidentifikasi keempat area itu dan kami empat area yang kami tetapkan untuk setiap pusat pengembangan.

Luca: Jelas ada beberapa titik kontak antara area tersebut, tetapi kemudian ada cara yang bisa Anda katakan untuk mengurangi dan mengadakan lokakarya awal dengan tim berbeda yang berada di lokasi berbeda dan kemudian bekerja menuju kontrak API yang sama misalnya, atau tujuan yang sama dengan memiliki beberapa pos pemeriksaan selama pengembangan. Tetapi hal menyenangkan dari pendekatan yang memungkinkan pendekatan dengan Micro-frontend adalah kenyataan bahwa kami akhirnya memahami secara mendalam bagaimana sistem kami bekerja. Kami duduk dan kami menganalisis bagaimana kami terstruktur dan kami mengubah tidak hanya cara kami memengaruhi berbagai hal, tetapi juga cara kerja perusahaan. Dan itu adalah semacam pendekatan yang berbeda dari apa yang telah mereka lihat sejauh ini. Tapi itu membuktikan bahwa bekerja cukup baik dalam kasus bahwa setiap tim tunggal dapat berinteraksi dengan tim dari lokasi yang sama di domain yang sama.

Luca: Jadi mereka berbicara dengan bahasa yang sama jika Anda berbicara tentang desain berbasis domain. Dan itu adalah bahwa jika mereka perlu berinteraksi dengan tim lain, mereka benar-benar dapat berbagi lokakarya atau terbang ke pusat pengembang lain dan itu tidak menjadi masalah. Tetapi dengan cara ini, katakanlah, menambah throughput dan mengurangi overhead komunikasi, dan tingkat ketergantungan yang terjadi dalam situasi lain yang sedang mereka kerjakan.

Drew: Dan apakah semua tim ini harus menggunakan kerangka kerja JavaScript standar? Apakah mereka semua harus mengkode dalam hal yang sama, mereka semua harus Bereaksi atau Sudut atau untuk mengaktifkan interoperabilitas di antara mereka atau dapatkah orang menggunakan hal yang berbeda untuk mikro-frontend yang berbeda?

Luca: Ya. Jadi di DAZN kami memutuskan untuk mengiris secara vertikal Micro-frontend kami dan itu adalah keputusan yang memungkinkan kami memiliki kebebasan untuk memilih teknologi yang kami butuhkan untuk setiap Micro-frontend tunggal. Mempertimbangkan bahwa setiap kali kami memuat satu Mikro-frontend per waktu dan ini berarti bahwa misalnya, bagaimana kami memiliki halaman arahan berbeda dari perjalanan masuk / mendaftar. Jadi kami dapat memperbarui ... kami terutama menggunakan React saat ini. Tetapi jika, misalnya, saya ingat ketika React 16 adalah rilis yang dapat kami rilis di React 16 produksi, juga jika itu tidak dalam versi stabil hanya untuk halaman arahan dan lihat apakah itu berfungsi tanpa mempengaruhi semua tim lain.

Luca: Dan kemudian dengan kecepatan mereka sendiri, dengan kecepatan mereka sendiri, mereka memperbarui barang-barang mereka sendiri. Sehingga memungkinkan kita juga untuk misalkan mencoba teknologi baru atau asumsi baru yang kita miliki pada aplikasi yang sudah ada dengan jumlah pengguna tertentu. Karena kami juga mengimplementasikan rilis kandidat untuk front end. Kami menerapkan, katakanlah beberapa praktik yang memungkinkan kami untuk mencoba waktu tertentu dalam produksi dan melihat cara kerjanya.

Luca: Keindahan dari pendekatan ini yang dapat kita putuskan sendiri untuk memiliki alat yang tepat untuk pekerjaan yang tepat lebih dari memiliki penyebut yang sama di seluruh tumpukan. Karena seperti yang dapat Anda bayangkan, ketika Anda mulai mengerjakan sebuah proyek, keputusan yang Anda buat beberapa tahun pertama mungkin berbeda dengan keputusan yang Anda buat dalam lintasan di mana perusahaan tumbuh, bisnis berkembang dan ini menjadi lebih matang. dan tantangannya sangat berbeda. Jadi itu tidak akan cukup fleksibel atau cukup gesit, jika Anda memikirkannya, fakta bahwa kami tetap pada keputusan yang sama yang kami ambil dua tahun lalu. Khususnya institusi seperti DAZN, yang pada dasarnya kami pindahkan dari nol menjadi 3000 karyawan dalam tiga tahun. Jadi seperti yang dapat Anda bayangkan, ini adalah pertumbuhan besar-besaran dan pertumbuhan besar-besaran bagi perusahaan serta basis pengguna.

Drew: Apakah ada cara yang mapan untuk Micro-frontend yang berbeda untuk berbagi data dan berkomunikasi satu sama lain, misalnya, hanya untuk menjaga satu sama lain dalam langkah dengan tampilan yang sama atau apakah ada cara untuk melakukannya?

Luca: Ya, ada. Itu tergantung kerangka keputusan mana, jalan mana yang akan Anda ambil. Karena jika akan mengambil irisan vertikal itu menjadi sangat mudah. Jadi yang kami miliki untuk berkomunikasi melalui Micro-frontend adalah shell aplikasi yang dimuat di Micro-frontend di dalamnya. Dan apa yang dilakukannya adalah menyimpan semua yang harus, katakanlah, dibagikan di berbagai Micro-frontend atau di penyimpanan web, baik sesi atau penyimpanan lokal atau di memori. Dan kemudian berdasarkan informasi tersebut, Micro-frontend dimuat, dapat mengambil dari shell aplikasi ke informasi ini dan kemudian menggunakan itu, mengubahnya atau mengubahnya. Terserah bagaimana Anda mengiris aplikasi, tetapi dalam kasus ini, hanya untuk memberikan contoh, jika Anda berpikir ketika Anda mengautentikasi pengguna dan Anda perlu pergi ke halaman masuk, ketika Anda masuk dan API digunakan dan mereka menyediakan token JWT, Micro-frontend meneruskan ini ke shell aplikasi dan shell aplikasi ini mulai kami menyimpan penyimpanan web mereka.

Luca: Kemudian setelah itu shell aplikasi memuat area terautentikasi baru untuk aplikasi tertentu dan area yang diautentikasi tersebut, mereka mengambil token JWT dari shell aplikasi dan melakukan token akses penyegaran atau memvalidasi beberapa data yang dimulai di dalam token JWT. Jadi pada dasarnya menggunakan informasi yang dihasilkan oleh Micro-frontend lain di roda mereka sendiri.

Drew: Kedengarannya seperti konsep yang sangat menarik dan saya berpotensi dapat melihat banyak keuntungan besar untuk bekerja dengan cara ini, tetapi itu tidak bisa tanpa tantangan, tentu saja. Apakah ada hal-hal tertentu yang lebih sulit untuk ditangani ketika merancang sesuatu dengan cara ini?

Luca: Saya pikir pertama dan terutama tantangan utama yang saya lihat adalah perubahan pola pikir. Karena sebelum kita terbiasa memiliki, katakanlah, pimpinan teknologi atau pengembang utama yang memutuskan segala sesuatu di seluruh aplikasi mengambil semua keputusan. Sekarang akhirnya kita pindah dari entitas terpusat ini ke entitas desentralisasi yang bersifat lokal untuk setiap negara bagian. Seperti yang dapat Anda bayangkan, ini membawa beberapa tantangan karena jika sebelumnya kita memiliki seseorang yang menelusuri jalan, sekarang kita memiliki, katakanlah, beberapa orang di atas mendefinisikan jalan yang benar di dalam domain mereka, dan ini adalah perubahan besar dari pola pikir.

Luca: Di sisi lain, saya pikir kompleksitas menerima kadang-kadang bahwa Anda melakukan abstraksi yang salah bisa, katakanlah, lebih mahal daripada kode duplikasi. Dan itulah yang saya tahu ada sesuatu yang menurut saya sangat menantang dalam mengelola pengembang karena mereka berpikir, "Oke, sekarang saya dapat menggunakan kembali objek ini atau perpustakaan khusus ini ratusan kali di dalam proyek," tetapi kenyataannya sangat berbeda. Saya melihat pustaka komponen yang abstrak dan mereka menghabiskan banyak waktu menjadikannya sebagai kode terbaik yang pernah ada atau yang terbaik dalam bentuk yang sempurna. Tetapi kenyataannya digunakan hanya dua kali. Jadi upaya melakukan itu, tidak persis seperti itu. Saya melihat di perpustakaan sisi lain bahwa mereka mulai dengan beberapa kasus penggunaan untuk komponen tertentu. Dan kemudian kasus penggunaan itu menjadi 10 dan kemudian kodenya menjadi tidak dapat dipertahankan.

Luca: Jadi mencoba menambahkan fungsi baru di dalam komponen yang sama bisa lebih berisiko daripada menguntungkan. Jadi saya pikir hal lain yang perlu kita pahami dengan Micro-frontend adalah seberapa banyak kita ingin membagikannya dan seberapa banyak kita ingin menduplikasinya. Dan tidak ada salahnya, jujur, menduplikasi. Dalam kasus kami misalnya, kami memiliki duplikasi footer dan header, dan kami melakukannya terutama karena kami mengubah tiga kali header dalam empat tahun. Jadi seperti yang dapat Anda bayangkan fakta bahwa kami memusatkan ini, ditugaskan ke tim dan membuat ketergantungan eksternal untuk semua tim, semua ratusan pengembang yang kami miliki, katakanlah masalah yang menguntungkan bagi perusahaan karena kami tidak menambahkan nilai yang sangat besar.

Luca: Pada saat yang sama saat ini kami sedang refactoring, perpustakaan bersama kami yang akan menjadi perpustakaan pembayaran, karena jelas pembayaran memiliki beberapa logika di balik itu dan jika kami ingin mengubah sekali, kami tidak ingin menerapkannya dua kali di beberapa bagian kode. Kami ingin memiliki satu perpustakaan saja yang menjadi sumber kebenaran, tetapi untuk header dan footer, juga jika ada ketidaksesuaian atau untuk piksel atau ada fungsi yang di-deploy seperti seminggu kemudian, tidak ada salahnya aplikasi.

Drew: Jadi, apakah ada beberapa tanda yang harus dicari orang ketika mengevaluasi aplikasi dan berpikir, "Oh ya, ini akan menjadi kandidat yang baik untuk pindah ke jenis arsitektur Micro-frontend?"

Luca: Ya, jadi saran saya yang pertama dan terutama saya tidak akan memulai proyek greenfield dengan Micro-frontend kecuali kita tahu persis bagaimana itu harus dibangun. Dan biasanya sangat kecil kemungkinannya Anda memiliki informasi ini karena, terutama jika Anda memiliki platform baru atau proyek baru dan ini adalah pertama kalinya Anda mengerjakan ini, mungkin tidak mudah untuk menemukan informasi ini. Biasanya yang saya sarankan adalah memulai dengan arsitektur yang sudah ada yang akan menjadi aplikasi satu halaman dan kemudian mengembangkannya. Secara khusus misalnya saya menemukan, saya pikir menggunakan Micro-frontend untuk aplikasi lama atau ketika kami ingin mengganti bagian tertentu dari aplikasi atau ketika kami memiliki proyek yang ingin kami kembangkan dan skalakan untuk banyak tim, itu adalah tiga kasus penggunaan yang saya rasa sangat kuat dapat disesuaikan dengan arsitektur Micro-frontend. Jelas bukan berarti mulai sekarang semuanya harus dibuat Micro-frontend, karena Micro-frontend sama sekali bukan peluru perak.

Luca: Apa itu arsitektur tambahan yang dapat kita manfaatkan di dunia ujung depan. Dan sampai sekarang kami memiliki sejumlah arsitektur, sekarang kami memiliki satu tambahan. Tapi itu banyak tantangannya karena jelas Anda perlu, jika sebelum rendering sisi server atau aplikasi satu halaman, ada pola yang jelas yang dieksplorasi dan kemudian diimplementasikan oleh beberapa kerangka kerja dan seterusnya. Dengan Micro-frontend saat ini, adalah salah satu cara untuk melakukan sesuatu. Tetapi menambahkan kerangka keputusan mungkin harus memungkinkan orang membuat keputusan yang tepat untuk kasus penggunaan mereka. Karena seringkali ada banyak kesalahpahaman tentang apa itu Micro-frontend dan bagaimana penggunaannya. Dan banyak orang berpikir bahwa mungkin katakanlah, jahat karena, saya tidak tahu, memiliki terlalu banyak perpustakaan dalam satu tampilan atau hal lainnya.

Luca: Kenyataannya adalah Anda perlu memahami konsepnya secara mendalam, memahami bagaimana menerapkannya dan kemudian Anda dapat mulai mengerjakannya. Saya sepenuhnya setuju bahwa ada tantangan teknis dan ada banyak keputusan yang harus Anda buat dan Anda tidak bisa langsung memulai dengan editor di depan Anda menulis kode dan berpikir, oke, sekarang saya sedang membuat mikro-frontend Arsitektur. Karena Anda perlu memahami konsepnya, memahami konteksnya dan membuat, juga tata kelola di sekitarnya karena kerumitannya tidak hanya menulis kode, tetapi juga memahami bagaimana semua bagian disatukan di bagian CICD bagian SEO dan seterusnya.

Luca: Jadi Micro-frontend memang memberikan, katakanlah tingkat fleksibilitas dan membutuhkan banyak upaya untuk mendefinisikan hak tata kelola. Karena ketika Anda memiliki pemerintahan yang benar, semuanya akan lancar. Seringkali dan sayangnya saya akan mengatakan terlalu sering, saya melihat perusahaan di mana mereka tidak menghabiskan cukup waktu di sisi tata kelola, memahami CICD misalnya, karena mereka tidak menganggap ini penting. Tetapi alih-alih untuk Micro-frontend, seperti untuk layanan mikro, memiliki hak otomatisasi akan memungkinkan Anda untuk mempercepat pengembangan. Jika Anda tidak menghabiskan cukup waktu untuk bagian otomatisasi, Anda berisiko memiliki lebih banyak beban daripada manfaat.

Drew: Saya kira itu seperti banyak hal di dunia pengembangan web di mana orang-orang berada dalam bahaya menyelam dengan solusi teknis sebelum mereka benar-benar memahami masalahnya. Dan sepertinya dengan Micro-frontend sangat banyak kasus yang Anda butuhkan untuk melihat masalahnya dan kemudian menerapkan solusi untuk mengetahui masalah apa yang Anda pecahkan. Saya kira sifat dari Micro-frontend membuatnya sangat mudah untuk mulai mengintegrasikan ke dalam aplikasi yang ada, untuk menemukan masalah kecil dan menukarnya dengan Micro-frontend untuk menyelesaikan masalah itu. Apakah itu saran yang masuk akal?

Luca: Ya, saya akan mengatakannya. Dalam hal ini, satu-satunya hal yang saya sarankan jika kita mulai dengan cara ini adalah melihat lebih banyak pada pengirisan vertikal daripada pengirisan horizontal, karena jika tidak, Anda perlu menyelesaikan begitu banyak masalah, mari kita asumsikan bahwa misalnya Anda menggunakan Angular dan Anda ingin pindah ke versi baru Angular. Jika Anda perlu memiliki dua versi Angular yang hidup bersama tanpa menggunakan I-frame, itu bisa rumit atau bahkan tidak mungkin. Jadi jika Anda memulai, aspek Anda bukan dari ... jika Anda memeriksa tantangan, bukan dari sudut pandang teknis, tetapi dari sudut pandang bisnis. Mungkin misalnya, Anda dapat mengambil, saya tidak tahu, bagian masuk yang ingin Anda tulis dengan versi yang berbeda atau versi yang sama tetapi lebih memperbarui versi kerangka kerja dan itu bisa menjadi cara yang baik. Dan kemudian Anda merutekan melalui jalan setapak. Itu bisa menjadi cara yang baik untuk mengganti aplikasi tertentu secara perlahan tapi mantap.

Luca: Apa yang telah kami lakukan dalam kasus kami pada dasarnya menerapkan pola pencekik yang merupakan pola terkenal untuk layanan mikro, tetapi di ujung depan. Jadi berdasarkan URL dan berdasarkan browser dan negara pengguna. Jadi perlahan tapi mantap, pada dasarnya kami membunuh monolit, yang dalam hal ini adalah aplikasi satu halaman, merilis aplikasi baru kami lebih sering dan melihat perilaku pengguna, jika itu meningkatkan pengalaman, itu menyebabkan masalah pada sistem kami atau tidak. Dan itu memungkinkan kami untuk memberikan nilai langsung pada bisnis, tetapi pada saat yang sama memungkinkan kami menguji asumsi kami dan melihat apakah kami menuju ke arah yang benar atau tidak.

Drew: Kedengarannya seperti solusi yang sangat menarik untuk beberapa masalah yang saya yakin banyak orang hadapi. Jika saya, sebagai pengembang, ingin mulai menyelidiki lebih lanjut tentang Micro-frontend, di mana tempat yang baik untuk memulai?

Luca: Ya, jadi saat ini saya menghabiskan banyak waktu luang saya mencoba mengadvokasi arsitektur ini, karena saya pikir ada banyak kesalahpahaman. Di akun Medium saya. Saya telah menulis beberapa artikel yang tersedia di sana juga. A merekam banyak video dalam konferensi yang dapat Anda temukan di YouTube tanpa masalah. Dan hal lain yang saya sarankan jika Anda mencari beberapa contoh kode pada beberapa kerangka kerja, yang akan saya rekomendasikan untuk memulai adalah SPA tunggal, terutama karena ia memiliki pendekatan pengirisan vertikal, lebih mudah untuk mengambilnya dan Anda dapat mulai memahami manfaat dari arsitektur ini. Lalu masih banyak lagi yang tersedia. Before I mentioned Luigi framework, as well as many others that are currently out there that are allowing you to compose multiple Micro-frontends in the same view.

Luca: Like another one in my head is TailorJS is another interesting. But definitely there is open components that is one developed by Open Table. But in general there are plenty of opportunity if you start to search about Micro-frontend, they're out there.

Drew: That sounds great. Is there anything else that you wanted to talk about with regard to the Micro-frontends?

Luca: Yeah. Personally I would suggest to take an open mind approach on learning this architecture and this approach, technical approach, mainly because I believe that there is a lot of good, but we need to, let's say, invest a bit of time and spend a bit of time to deeply understand how the things are working. Because obviously there isn't, just one way to do things. We are used that we take a framework and immediately we start to work on it and it's super productive, if you think about that.

Luca: But in this case you need to spend a bit of more time understanding, as you said a couple of times, the problem. Understand which is the pattern that would allow you to express better not only from a technical point of view but those two from our organizational point of view, the solution that you have in mind.

Drew: So I've been learning all about Micro-frontend today. What have you been learning about lately?

Luca: Recently there are two things that I'm learning. So last week I was in Las Vegas during the AWS event and is obviously a cloud conference. Pretty amazing, 70,000 people, a lot of sessions that were spreading several hotels in Vegas. And there for me, a serverless is a paradigm that I'm studying the most because I truly believe that in the future that will be the way how we are going to design and implement software and obviously AWS is very prominent on this approach.

Luca: And the second topic is around management and how to be a leader of a tech team. Because obviously I'm SVP of architecture. I have a team of architects that I'm leading and you can never rest because you need to not only to be on top of the technical side, but you need also to understand the people problems, understand how you can make them successful. Because obviously if they are successful, you are successful. You are first a technical facilitator to a certain extent. So that for me, those for me are the two things that currently I'm studying on top of exploring the Micro-frontend world.

Drew: If you, dear listener, would like to hear more from Luca, you can follow him on Twitter where he's @LucaMezzalira or find his activities collected together at Lucamezzalira.com. Thanks for joining us today, Luca. Did you have any parting words?

Luca: No, but thank you very much for listening up to now.