Luca Mezzalira ile Çarpıcı Podcast 6. Bölüm: Mikro Ön Yüzler Nelerdir?

Bu yılı bir başka Smashing podcast'iyle kapatıyoruz! Bu sefer mikro önyüzlerden bahsedeceğiz. Mikro önyüz nedir? Şu anda benimsemiş olabileceğimiz türden bir yaklaşımdan ne farkı var? Mikro ön uç öncüsü Luca Mezzalira'dan öğrenelim.

Notları göster

Haftalık güncelleme

• Jason Lengstorf “JAMstack Sitelerine Dinamik ve Zaman Uyumsuz İşlevsellik Ekleme”
• Adonis Raduca “UX Tasarımcıları İçin Nicel Veri Araçları”
• Tris Tolliday, "Google Asistan ve Amazon Alexa için Ses Becerileri Oluşturma"
• Shamsi Brinn, "Sprint 0'ın Ötesinde: Takımları Bütünleştirmek İçin Bir Alternatif"
• "CSS Özelliği İçererek Tarayıcıların Optimize Edilmesine Yardımcı Oluyor" Rachel Andrew

Mikro Ön Yüzler

• Luca Mezzalira'nın web sitesi
• Twitter'da Luca
• Medium'da “Micro-Frontends, Frontend Mimarilerinin Geleceği”
• Luca'nın mikro ön uçlar hakkında daha fazla yazısı Medium hesabında bulunabilir.
• Luca'nın “Ön Uç Reaktif Mimarileri” kitabı

Transcript

Drew McLellan: Web teknolojileri konusunda bir Google geliştirici uzmanı ve Londra JavaScript topluluğunun yöneticisidir. 15 yılı aşkın tecrübesiyle şu anda Mimari Başkan Yardımcısı olarak çalışıyor ve isteğe bağlı spor içeriğini milyonlarca kullanıcıya canlı izleyen spor video platformu DAZN'yi tasarlıyor. Apress için Front-End Reactive Architectures kitabının yazarıdır ve aynı zamanda Apress, Packt Publishing, Pragmatic Bookshelf ve O'Reilly için teknik bir eleştirmendir ve ayrıca dünyanın her yerindeki teknik konferanslarda deneyimli bir konuşmacıdır. İtalyan, yakışıklı bir sakalı var ve web platformu hakkında derin bilgiye sahip olduğu açık. Ama bir zamanlar Güney Amerika'yı bir devekuşu üzerinde geçtiğini biliyor muydunuz? Ezici dostlarım, lütfen Luca Mezzalira'ya hoş geldiniz. Merhaba, Luca. Nasılsınız?

Luca Mezzalira: Eziyorum .

Drew: Bugün sizinle mikro önyüzler hakkında konuşmak istiyorum. Şimdi bu benim için tamamen yeni bir kavram, kesinlikle ismiyle ve pek çok dinleyicimiz için de yeni olmasını bekliyorum. Mikro ön uçlara girmeden önce, sanırım onlarla çözmeye çalıştığınız sorunu anlamalıyız. Belki de bize uygulamaları daha geleneksel bir şekilde nasıl gördüğünüzden ve bu şeyler ne tür sorunlara yol açtığından, belki de mikro önyüzlerin çözüm olabileceğinden biraz bahsedebilirsiniz?

Luca: Tamam, bence bu iyi bir başlangıç ​​noktası. Bu nedenle, genellikle yeni bir yeşil alan projesi uyguladığınızda veya tasarladığınızda ve ön uç uygulamalarla çalışmak istediğinizde, yararlanabileceğiniz birkaç mimariniz olur. Tek sayfalık bir uygulama kullanabilir, bir sunucu tarafı oluşturma uygulaması kullanabilirsiniz veya sadece basit HTML sayfalarından oluşan çok sayfalı bir uygulama kullanabilirsiniz. Açıkçası bunlar süper geçerli seçenekler ve bence birçok geliştirici tarafından çok kullanılıyor. Burada çözmeye çalıştığımız asıl sorun, bu kavramları dağıtılmış ekiplerle aynı kod temeli üzerinde çalışan yüzlerce geliştiriciye nasıl ölçeklendirebileceğinizdir, çünkü gerçek şu ki, özellikle bu platformlarda çalışırken, düşündüğünüzde Örneğin SaaS platformu, aynı proje üzerinde çalışan birden fazla geliştiriciye ve birden fazla ekibe sahip olmanız gerekir. Ve açıkçası, örneğin edinme veya elde tutma yönteminiz, kataloğu nasıl gösterdiğiniz veya bir platformun belirli bir bölümünü nasıl gösterdiğiniz konusunda tamamen farklıdır.

Luca: Şimdi deneyimlerime göre tek sayfalık uygulamalarla çok çalışıyorum. Sunucu tarafı işleme uygulamasıyla çalışıyorum, ancak DAZN'de bir noktada teknik ekibimizi ölçeklendirmenin bir yolunu düşünmem istenecek. Arka uç için bu durumda mikro hizmetler olan bir çözümümüz varsa, bu nedenle API'lerimizi bağımsız olarak ölçeklendirebiliriz ve belirli bir API'deki belirli bir verimin ölçeğini ve hacmini göz önünde bulundurabiliriz. Ön uçta, gerçekten, gerçekten daha zor çünkü bunu düşündüğünüzde, örneğin tek sayfalık bir uygulama kullanıyorsanız, ölçeklendirmeniz gerektiğinde çözmeniz gereken teknik bir probleminiz yok. Muhtemelen sunucu tarafı oluşturma için bazılarınız vardır, ancak örneğin tek sayfalı bir uygulamada, istemci tarafında, farklı istemci tarafında olduğu için doğası gereği dağıtılır.

Luca: Yani yükledikleri tek şey, CDN tarafından sunulan CSS, HTML ve JavaScript gibi bazı statik dosyalar ve bu durumda buna göre ölçeklendirebilirsiniz, bu büyük bir zorluk değil. Ancak asıl zorluk, aynı platformda çalışan ekipleri nasıl ölçeklendirdiğinizdir, çünkü bazen bir takımın karşılaştığı zorluklar başka bir takımın karşılaştığı zorluklardan tamamen farklı olabilir ve genellikle yaptığınız şey bulmaya çalışmaktır. şeyler arasında çok fazla ödünleşim var. Çünkü düşünürseniz normal bir kullanım durumu üzerinde düşünmeye çalışalım. Bu nedenle, genellikle bir platforma başladığınızda küçük başlarsınız. Böylece, tek sayfalık hızlı uygulamayı yaratmaya çalışıyorsunuz, monolitiniz de var, bu yüzden CICD'nizdeki her şeyi ön uç ve arka uç için sadece bir kez ayarladınız ve sonra mantığınızı yinelemeye başlıyorsunuz. Ancak gerçek şu ki, başarılı olduğunuzda, bu kısmı geliştirmeniz gerekiyor ve her zaman aynı mimariyi sürdürmek, örneğin işiniz için fayda yaratabilecek değil, çünkü belki bazı darboğazlar bulabilirsiniz.

Luca: Şimdi tek sayfalık uygulama kısmına dönüyoruz. Dolayısıyla, tek sayfalık bir uygulama bölümünü ölçeklendirmek istiyorsak, zorluk teknik değil, isterseniz insanlarla ilgili. Peki aynı uygulama üzerinde çalışan ekipleri nasıl ölçeklendirebiliriz. Birkaç yıl önce yaptığım şey, olası bir mimariye ve arka ucun yanı sıra ön ucu da ölçeklendirmeme izin verecek ilkelere bakmaya başlamaktı. Mikro hizmetleri bulabilmeniz için arka uç ilkeleri üzerinde çalışın. Farklı bir çözüme bakmaya başladım ve onlar mikro ön uçlarla ortaya çıktılar ki başlangıçta buna o şekilde bile demedik çünkü açıkçası yıllar önce, diyelim ki, o belirli mimari için bu isim yoktu. .

Luca: Ama gerçek bir monolit alıyor, yani tek sayfalık bir uygulama ve onu küçük bir probleme odaklanmamızı sağlayacak şekilde dilimliyor. Yani tüm uygulamadan daha küçük bir problem ve bunu mümkün olan en iyi şekilde çözmeye çalışmak. Teknik olarak konuşursak. Açıkçası bu, diğerlerini etkilemeden üretimde dağıtılabilecek ön uç uygulamanızın bağımsız parçalarına sahip olmanıza yol açar. Bu nedenle, temel olarak Micro-frontend için zorluk, tek sayfalık bir uygulama veya sunucu tarafında oluşturulmuş bir uygulama almanın ve bunların bir yapıtını, diyelim ki, bir iş alanına mümkün olduğunca yakın ve bağımsız olarak dağıtılabilir hale getirmenin yollarını bulmaya çalışmaktır. .

Drew: Yani arka uçta mikro hizmetlerden bahsettin. Yani kavramsal olarak bu, soruna benzer bir çözüm türüdür. Mikro hizmetler arka uçta hizmet verir, ancak ön uca taşınır. Bu kabaca bir denklik mi yoksa daha çok buna dahil mi?

Luca: Evet. Hayır, mikro hizmetleri arka uçta, ancak bu sefer ön uçta çözmeye çalıştığı sorunu çözmenin bir yolu. Genelde ben bu yolculuğa başladığımda, bilirsiniz, bunu düşünmeye başlıyorsunuz ve farklı yaklaşımları değerlendirmeye başlıyorsunuz. Ve son birkaç ayda onların dediğiyle karşılaştım, temelde dört adımdan oluşan Mikro ön uç karar çerçevesi, diyelim ki Mikro ön uç için bir yaklaşım belirlediniz, çünkü şimdiye kadar, genellikle bizim için mimariyi tasarlayan bir çerçeve seçer ve biz de onların mimarisinin üzerine uygularız. Açısal hakkında düşünüyorsanız veya React veya Redux hakkında düşünüyorsanız. İhtiyacınız olan tüm parçalara sahipsiniz ama mimari kararlar almıyorsunuz. Bir tasarım kararları veya bu belirli mimarinin üzerine nasıl uyguladığınız konusunda karar verirsiniz.

Luca: Yani Mikro ön uçta geri adım atmanız gerekiyor. Bu yüzden ilk önce uygulamamızı nasıl dilimlemek istediğimizi düşünmemiz gerekiyor. Yani bunun için genellikle iki seçenek vardır. Yatay olarak dilimleyebilir, böylece aynı görünümde birden fazla mikro ön yüze sahip olabilir veya dikey olarak dilimleyebilirsiniz. Bu nedenle, her zaman her zaman bir Mikro ön uç yüklersiniz. Ve bu kararlar oldukça önemlidir çünkü daha sonra vereceğiniz ilk karara dayalı olarak sahip olduğunuz diğer bazı seçenekleri basamaklandıracaktır. İlk olarak, dediğim gibi, uygulamanızı nasıl dilimlemek istediğinize siz karar verin. İkincisi, başvurunuzu nasıl oluşturmak istediğinizdir. Örneğin, aynı görünümde bir veya birden fazla mikro ön uç yükleyen bir uygulama kabuğuna sahip olmak istiyorsunuz. Bilmiyorum, uygulamalarınızın farklı parçalarını oluşturan uygulama sunucusuna, çok farklı Micro-frontend'e sahip olmak ve ardından kullanıcınıza son görünümü sunmak istiyorsunuz. Veya kenar tarafı dahil kullanmak istiyorsanız, bir sayfa oluşturmak ve bunları orada sunmak için CDN'lerin içinde bulunan bir standarttır.

Luca: Bunlar sahip olduğun üç seçenek. Ve beste yapmanın yanı sıra, nasıl yönlendirmek istediğinizi de düşünmeniz gerekiyor. Öyleyse, nasıl yönlendiriyorsunuz, bilmiyorum, /login veya /signin, katalog bölümüne veya belirli bir detay nesnesine. Ayrıca burada üç seçeneğiniz var. Bunu uygulama sunucusunda yapabilirsiniz, Lambda Edge veya CloudFlare'deki diğer web çalışanları veya başka herhangi bir şey ile CDN düzeyinde yapabilirsiniz. Veya bir müşteri sitesi yapabilirsiniz. Bu nedenle, uygulama kabuğunuzun içinde, tamam, şimdi bu belirli URL için başka bir görünüm veya başka bir mikro ön uç yüklemeniz gerektiğini söyleyen bir mantığınız var. Ve son kısım, Micro-frontend ile nasıl iletişim kurduğunuzdur.

Luca: Yani genellikle aynı sayfada birden fazla Micro-frontend'iniz varsa, bu iletişimi yönetmek daha karmaşıktır, çünkü farklı Micro-frontend'i bağımsız tutmanız gerekir. Bu, sayfanın nasıl yapılandırıldığına dair herhangi bir referansınız olamayacağı anlamına gelir. Bu nedenle, genellikle özel olaylar veya her bir Mikro ön ucun içine enjekte edilen bir olay ölçer gibi şeyler kullanabilirsiniz. Ve sonra Mikro ön uç birlikte iletişim kuruyor. Açıkçası, diğer durumda, istediğiniz zaman, diyelim ki Mikro ön ucunuzdan dikey bir bölünme çok daha kolaydır, çünkü dikeyin içinde temel olarak dikey bir Mikro ön ucun temsili, tek sayfalık bir uygulama veya tek bir sayfadır. Ve bu durumda, tüm Micro-frontend genelinde paylaşılan bir duruma sahip olarak oluştur ve paylaş diyelim.

Luca: O zaman birden fazla Mikro-önyüzün bir arada olmasını düşünüyorsanız, o zaman Mikro-önyüzde paylaşılan durumlara sahip olmaktan kaçınmalısınız, çünkü aksi takdirde bir şeyleri birleştiriyorsunuz. Buradaki tüm kavram yerine ayrıştırma ve bağımsız dağıtım var. Bu nedenle, almanız gereken ilk karar olan yatay bölmenin veya dikey bölmenin zorluklarının tamamen farklı olduğunu ve hangisinin kullanım durumumuza uyduğunu çok iyi bilmemiz gerektiğini varsayalım.

Drew: Yani, belirli bir teknik çözümden ziyade, mikro ön uçlar, çözmeye çalıştığınız belirli sorun için uygun teknoloji ne olursa olsun uygulayacağınız bir tasarım modeline çok benziyor?

Luca: Evet, teknolojiden çok, doğru iş için doğru mimariyi seçtiğimizi görüyorum. Sadece bir örnek vermek gerekirse, konuşuyordum … ünlü bir çerçeve var, Micro-frontend için oldukça yeni, buna Luigi çerçevesi deniyor, SAP açık kaynak tarafından yayınlandı. Yaptıkları şey, Mikro ön uçlarını içine sardıkları bazı iframe'ler oluşturmak. Şimdi bunu düşünürseniz, diyelim ki, günümüzde iframe'leri kullanarak, halka açık bir web sitesindesiniz, belki SEO veya zorunlu olan diğer özellikler olarak sorunlu olabilir.

Luca: Ama SAP örneğinde, bunu düşünürseniz, kullanıcının kullandığı tarayıcıyı kontrol edebilecekleri, ortamı kontrol edebilecekleri, çok sayıda veya çok sayıda erişilebilir olmalarına gerek olmayan kurumsal bir uygulamaya sahipler. tarayıcının farklı sürümü. Yani onlar için bu şey onların sabit olan belirli uygulama alanlarına sahip olmalarını ve herhangi bir problem olmadan bağımsız olarak değişen belirli alanlara sahip olmalarını sağlar. Ama açıkçası bir iframe çözümü başka bir durumda işe yaramaz. Başka bir örnek vermek gerekirse, Spotify, başlangıçta iframe'leri kullanıyoruz. Aslında, masa yayını hala birden çok iframe'den oluşuyor ve her bir iframe, bilmiyorum, sadece bir müzik çalar veya sadece onların tavsiyesi, her ne ise, yapan küçük bir uygulamadır. Web'de de aynı yaklaşıma sahip olmaya çalışıyorlar, ancak bu yıl tek sayfalık bir uygulamaya geri dönmek için bunu reddettiler.

Luca: Ve bunun anlamı, teknik blogda, bunu açık bir şekilde, aynı satıcı dosyasının her seferinde yüklenmesi gereken iframe kullanan milyonlarca kullanıcıya uygularsanız, açıkladıklarını söylüyorlar. Ve sonra, çoğaltılmış çok sayıda bağımlılığınız var ve sayfanızla etkileşime girme süresi daha uzun olacaktır. Yani gerçekte, bu yaklaşım belirli kullanım durumları için uygun olabilir, ancak hepsine uymamalıdır. İşte bu yüzden diyorum ki, daha önce de belirttiğim gibi, bu şeyleri ele almanıza yardımcı olacak bir karar çerçeveniz varsa ve 'tamam, uygulamayı bu şekilde dilimledim, bu yüzden mevcut seçeneklere sahibim' diyebilirsiniz. beste yapmak istediğimde, yönlendirmek istediğimde, iletişim kurmak istediğimde doğru zamanda doğru kararı verebilmek için size yol göstermesi gerekir.

Luca: O zaman açıkçası bu dört kararın dışında başkaları da var. Tüm Mikro ön uçta sahip olduğunuz tasarım sisteminde nasıl tutarlılık yarattığınız gibi. Ya da bağımlılıkları nasıl yönettiğinizi ve Micro-frontend içindeki bağımlılığın çatışmasını nasıl önlediğinizi bilmiyorum, ama gerçek şu ki, daha önce bahsettiğim bu dört karar, diğerlerini hızlı bir şekilde almanıza izin verecek. En iyi çözüm olan aşırı düşünme sorunu, çünkü temel taşını, diğer tüm kararları vermenizi sağlayacak dört sütunu zaten belirlemişsiniz… Kolay bir şekilde söylemiyorum, ama bir incelemeden daha hızlı bir şekilde ya da fırsatlar yelpazesi.

Drew: Daha önce Micro-frontend'in kuruluşunuzdaki ekiplerin yapısına ve aynı uygulama üzerinde çok sayıda insanın çalışmasına yardımcı olabileceğinden bahsettiniz. O zaman bunun sonuçlarından bazıları nelerdir ve ekiplerinizin dağıtılmış olması veya aynı yerde bulunması veya orada karşılaşılan herhangi bir zorluk olması herhangi bir fark yaratır mı?

Luca: Evet. Böylece size DAZN'ın hikayesini anlatabilirim. Üzerinde çalıştığım şirket bu. Şu anda DAZN'de güzel bir meydan okuma yaşadık. Dolayısıyla şu anda platformumuzun ön ve arka ucunda çalışan 300'den fazla insanımız var. Dünya çapında spor etkinliklerinde canlı yayın yapan bir OTT platformudur. İşin ilginç yanı, tüm mikro hizmetlerin az çok nasıl yönetileceğini bildiğimiz ve ekipleri dağıtmış olmamızdır. Yani dört geliştirme merkezimiz var. Ön taraftaki her bir geliştirme merkezine ekipler yerleştirmek isterdik ve bu yaklaşımı denedik ve oldukça iyi çalışıyor. Böylece Micro-frontend ile farklı konumlarda farklı iş alanları sağlayabildik ve belirli bir iş alanı içindeki ekipler arasında çapraz iletişime izin verebildik, çünkü en kötü durum senaryosu, aynı iş alanınızda başka bir ekiple konuşmanız gerekiyorsa. , sadece masanızdan yürüme mesafesine ulaşıyorsunuz. Bunun yerine dağıtım ekibinde belirli bir şeyi tartışmanız gerekiyorsa, yani belki Amsterdam yerine Londra'daki veya Polonya'daki bir şirket yerine biriyle görüşmeniz yeterlidir.

Luca: Ancak bu tür iletişimler, aynı konumdaki ekipler arasında gerçekleşenlerden daha nadirdir. Ve bu yüzden bunun üzerinde çalışmaya başladık. Bu yüzden ilk yaptıkları şey, kullanıcılarımızın web sitemizle nasıl etkileşime girdiğine, şirketin nasıl yapılandırıldığına bakmak oldu. Ve üzerinde çalıştığımız, şu anda edinme ve elde tutma olan dört temel alanı belirlediğimizde, diyelim ki temel uygulamalarının birden fazla TV'ye ve mobil cihaza taşınması ve bizim için video oynatıcı ve keşif aşaması olan çekirdek alana sahip olun. içeriğimiz. Ve son olarak tüm arka ofis unsurları. Bu dört alanı ve her bir geliştirme merkezi için atadığımız dört alanı tanımlayabildim.

Luca: Açıkçası, bu alanlar arasında bazı temas noktaları var, ancak daha sonra, farklı konumlarda bulunan ve daha sonra aynı API sözleşmesi için çalışan farklı ekiplerle, hafifletme ve bazı başlangıç ​​atölyeleri gerçekleştirmenin yolları var, veya geliştirme sırasında bazı kontrol noktalarına sahip olmakla aynı amaç. Ancak Micro-frontend ile yaklaşmaya izin veren yaklaşmanın güzel yanı, nihayet sistemimizin nasıl çalıştığını derinlemesine anladığımız gerçeğidir. Oturuyoruz ve nasıl yapılandırıldığımızı analiz ediyoruz ve sadece olaylardan nasıl etkilendiğimizi değil, aynı zamanda şirketin nasıl çalıştığını da değiştirdik. Ve bu, şimdiye kadar gördüklerinden farklı bir yaklaşımdı. Ancak, her bir ekibin aynı etki alanındaki aynı konumdaki ekiple etkileşime girebilmesi durumunda bunun oldukça iyi çalıştığını kanıtlıyor.

Luca: Yani etki alanına dayalı tasarımdan bahsediyorsanız, tamamen aynı dilde konuşuyorlar. Ve eğer diğer ekiplerle etkileşime girmeleri gerekiyorsa, atölyeyi tam anlamıyla paylaşabilir veya başka bir geliştirme merkezine uçabilirler ve bu bir problemden daha azdır. Ancak bu şekilde, verimi artırın ve iletişim yükünü ve üzerinde çalıştıkları diğer durumlarda meydana gelen bağımlılıkların boyutunu azaltalım.

Drew: Peki tüm bu ekiplerin standartlaştırılmış bir JavaScript çerçevesi gibi mi kullanması gerekiyor? Hepsinin aynı şeyleri kodlaması mı gerekiyor, hepsinin React veya Angular olması veya aralarında birlikte çalışabilirliği sağlamak için mi yoksa insanlar farklı Mikro önyüz için farklı şeyler kullanıyor olabilir mi?

Luca: Evet. Böylece DAZN'de Mikro önyüzümüzü dikey olarak kesmeye karar verdik ve bu, her bir Mikro önyüz için ihtiyaç duyduğumuz teknolojiyi seçme özgürlüğüne sahip olmamızı sağlayan bir karardı. Her seferinde bir Mikro ön uç yüklediğimizde ve bu, örneğin, bir açılış sayfamızın nasıl olduğunu, oturum açma / kaydolma yolculuğundan farklı olduğu anlamına gelir. Böylece güncelleme yapabiliriz… şu anda esas olarak React kullanıyoruz. Ancak, örneğin, React 16'nın üretim React 16'da yayınlayabildiğimiz bir sürüm olduğunu hatırlıyorum, ayrıca kararlı sürümde yalnızca bir açılış sayfası için olmasaydı ve tüm özellikleri etkilemeden çalışıp çalışmadığına bakın. diğer takımlar.

Luca: Sonra kendi hızlarında, kendi hızlarında, kendi eşyalarını güncelliyorlardı. Bu da diyelim ki belirli sayıda kullanıcıyla mevcut uygulamada sahip olduğumuz yeni teknolojileri veya yeni varsayımları denememize izin veriyor. Çünkü ön uç için de aday sürümleri uyguluyoruz. Üretimde sadece belirli zamanları denememize ve işlerin nasıl yürüdüğünü görmemize izin veren birkaç uygulama diyelim.

Luca: Tüm yığında ortak bir paydaya sahip olmaktan çok, doğru iş için doğru araca sahip olmaya bağımsız olarak karar verebilmemiz bu yaklaşımların güzelliği. Çünkü tahmin edebileceğiniz gibi, bir proje üzerinde çalışmaya başladığınızda, şirketin büyüdüğü, işin geliştiği ve bunların daha da olgunlaştığı bir yörüngede aldığınız kararda, ilk birkaç yılda verdiğiniz karar muhtemelen farklıdır. ve meydan okuma tamamen farklıdır. Yani yeterince esnek veya yeterince çevik olmaz, bunu düşünürseniz, iki yıl önce aldığımız karara bağlı kaldığımız gerçeği. Özellikle DAZN gibi temelde sıfırdan üç yıl içinde 3000 çalışana geçtiğimiz bir kurum. Tahmin edebileceğiniz gibi, bu muazzam bir büyümeydi ve şirket için olduğu kadar kullanıcı bazında da büyük bir büyümeydi.

Drew: Farklı Micro-frontend'in verileri paylaşması ve birbirleriyle iletişim kurması için yerleşik bir yol var mı, örneğin, sadece aynı görüşte birbirini takip etmek için mi yoksa bunu yapmanın bir yolu var mı?

Luca: Evet, var. Hangi karar çerçevesinden, hangi yoldan gideceğinize bağlı. Çünkü dikey dilim alacaksanız bu çok kolay oldu. Mikro ön uç aracılığıyla iletişim kurmak için sahip olduğumuz şey, kendi içinde Mikro ön uçta yüklenen bir uygulama kabuğudur. Ve yaptığı şey, diyelim ki farklı Mikro ön uçta veya bir web deposunda, bir oturumda veya yerel depolamada veya bellekte paylaşılması gereken her şeyi depolamak. Ve sonra bu bilgilere dayanarak, Mikro ön uç yüklenir, uygulama kabuğundan bu bilgilere ulaşabilir ve ardından bunu tüketebilir, değiştirebilir veya değiştirebilir. Tamamen uygulamayı nasıl dilimleyeceğinize bağlı, ancak bu durumda, sadece bir örnek vermek gerekirse, ne zaman kimliği doğrulanmış kullanıcılar olduğunuzu ve oturum açma sayfasına gitmeniz gerektiğini düşünüyorsanız, ne zaman giriş yaptığınız ve API'ler bizim tükettiğimiz ve bir JWT belirteci sağlıyorlar, Micro-frontend bunları uygulama kabuğuna aktarıyor ve uygulama kabuğundan başlayarak web depolamalarını kurtardık.

Luca: Bundan sonra, uygulama kabuğu, o belirli uygulama ve bu kimliği doğrulanmış alanlar için yeni kimliği doğrulanmış alanı yüklüyor, uygulama kabuğundan JWT belirtecini alıyorlar ve bir yenileme erişim belirteci gerçekleştiriyor veya içinden başlayarak bazı verileri doğruluyorlar. JWT belirteci. Yani temelde başka bir Micro-frontend tarafından kendi çarkında üretilen bilgileri kullanıyor.

Drew: Kulağa çok ilginç bir konsept gibi geliyor ve bu şekilde çalışmanın potansiyel olarak birçok büyük avantajını görebiliyorum, ancak bunun zorlukları olmadan da olmayacağı kesin. İşleri bu şekilde tasarlarken ele alınması daha zor olan belirli şeyler var mı?

Luca: Bence her şeyden önce, gördüğüm ana zorluklar zihniyet değişimi. Çünkü önceleri, diyelim ki, tüm bir uygulama etrafında her şeye karar veren tüm kararları alan teknoloji liderleri veya lider geliştiriciler vardı. Şimdi nihayet bu merkezi varlıktan her eyalet için yerel olan merkezi olmayan bir varlığa geçiyoruz. Tahmin edebileceğiniz gibi, bu bazı zorluklar getiriyor çünkü daha önce yolu izleyen biri varsa, şimdi, diyelim ki, kendi alanlarında doğru yolu tanımlayan birden fazla insanımız var ve bu büyük bir değişim. zihniyetin.

Luca: Öte yandan, karmaşıklığın bazen yanlış soyutlama yapmanın, diyelim ki, kodu kopyalamaktan daha pahalı olabileceğini kabul etmek olduğunu düşünüyorum. Ve geliştiricileri yönetmede çok zorlayıcı bulduğum bir şey olduğunu biliyorum çünkü onlar "Tamam, şimdi bu nesneyi veya bu belirli kütüphaneyi proje içinde yüzlerce kez yeniden kullanabilirim" diye düşünüyorlar ama gerçek çok farklı. Soyut olan bileşen kitaplığı gördüm ve bunu şimdiye kadarki en iyi kod veya mükemmel bir şekilde en iyisi yapmak için çok zaman harcıyorlar. Ama gerçeklik sadece iki kez kullanıldı. Yani bunu yapma çabası, tam olarak bu değildi. Diğer taraftaki kitaplıklarda, belirli bir bileşen için birkaç kullanım durumuyla başladıklarını gördüm. Ve sonra bu kullanım durumları 10 oldu ve ardından kod sürdürülemez hale geldi.

Luca: Yani aynı bileşenin içine yeni bir işlev eklemeye çalışmak, faydadan çok risk altında olabilir. Bu yüzden Micro-frontend ile anlamamız gereken diğer şey, onu ne kadar paylaşmak istediğimiz ve ne kadar çoğaltmak istediğimizdir. Ve dürüst olmak gerekirse, çoğaltmanın zararı yoktur. Örneğin bizim durumumuzda altbilgi ve üstbilginin bir kopyası var ve bunu esas olarak dört yılda üstbilgiyi üç kez değiştirdiğimiz için yaptık. Bunları merkezileştirdiğimizi, bir ekibe atandığımızı ve tüm ekipler için, sahip olduğumuz yüzlerce geliştirici için bir dış bağımlılık yarattığımızı hayal edebileceğiniz gibi, şirket için bir fayda sağlayan bir konu diyelim çünkü çok büyük bir değer katmıyoruz.

Luca: Aynı zamanda, şu anda ödeme kitaplığı olacak paylaşılan kitaplıklarımızı yeniden düzenlemeye çalışıyoruz, çünkü ödemenin arkasında bir mantık var ve bir kez değiştirmek istersek, bunu birden çok bölümde iki kez uygulamak istemiyoruz. kod. Doğruluk kaynağı olan tek bir kitaplığımız olsun istiyoruz, ancak üstbilgi ve altbilgi için, ayrıca bir tutarsızlık veya piksel için veya bunun bir hafta sonra konuşlandırılacak bir işlevi varsa, zarar vermez. başvuru.

Drew: O halde, insanların bir uygulamayı değerlendirirken ve "Ah evet, bu bir Mikro-ön uç mimarisine geçmek için iyi bir aday olur mu?" diye düşünürken araması gereken bazı açıklayıcı işaretler var mı?

Luca: Evet, yani benim önerim, her şeyden önce, tam olarak nasıl inşa edilmesi gerektiğini bilmedikçe Micro-frontend ile sıfırdan bir projeye başlamam olurdu. Ve genellikle bu bilgilere sahip olmanız pek olası değildir, çünkü özellikle yeni bir platformunuz veya yeni bir projeniz varsa ve bunun üzerinde ilk kez çalışıyorsanız, bu bilgiyi bulmak önemsiz olabilir. Genellikle önerdiğim şey, tek sayfalık bir uygulama olacak mevcut bir mimariyle başlamak ve ardından bunu geliştirmek. Özellikle şunu buldum, eski uygulamalar için Micro-frontend kullanmanın veya uygulamanın belirli bir bölümünü değiştirmek istediğimizde veya geliştirmek ve birden fazla ekip için ölçeklendirmek istediğimiz bir projemiz olduğunda, bunlar üç kullanım durumudur. Kendimi çok güçlü hissettiğim şey Mikro ön uç mimarisine uygun olabilir. Açıkçası bu, bundan sonra her şeyin Micro-frontend yapılması gerektiği anlamına gelmez, çünkü Micro-frontend gümüş kurşun değildir.

Luca: Bunlar, ön uç dünyasından yararlanabileceğimiz ek bir mimaridir. Ve şimdiye kadar belirli sayıda mimarimiz vardı, şimdi bir tane daha var. Ancak bu çok fazla zorluktur çünkü açıkçası yapmanız gerekiyorsa, sunucu tarafı oluşturma veya tek sayfalı bir uygulamadan önce, keşfedilen ve ardından birkaç çerçeve tarafından uygulanan açık kalıplar varsa vb. Şu anda Micro-frontend ile işleri yapmanın bir yolu var. Ancak karar çerçevesini eklemek, muhtemelen insanların kullanım durumları için doğru kararları vermelerine izin vermelidir. Çünkü Micro-frontend'in ne olduğu ve nasıl kullanılması gerektiği konusunda çoğu zaman birçok yanlış anlama vardır. Ve birçok insan, bir görüşte veya başka şeylerde çok fazla kütüphaneye sahip olmak için, bilmiyorum, kötü olduğunu söyleyebiliriz.

Luca: Gerçek şu ki, kavramı derinlemesine anlamanız, bunu nasıl uygulayacağınızı anlamanız ve ardından bunun üzerinde çalışmaya başlayabilirsiniz. Teknik zorluklar olduğuna ve vermeniz gereken birçok karar olduğuna tamamen katılıyorum ve önünüzdeki bir editörle hemen kod yazmaya ve düşünmeye başlayamazsınız, tamam, şimdi bir mikro ön uç oluşturuyorum mimari. Kavramı anlamanız, bağlamı anlamanız ve bunun etrafında bir yönetim oluşturmanız gerektiğinden, karmaşıklık sadece kodu yazmak değil, aynı zamanda tüm parçaların CICD bölümünde SEO bölümünde nasıl bir araya geldiğini anlamaktır.

Luca: Yani Micro-frontend, diyelim ki bir düzeyde esneklik sağlıyor ve yönetişim hakkını tanımlamak için çok çaba gerektiriyor. Çünkü yönetim hakkınız olduğunda her şey yolunda gidecektir. Çoğu zaman ve ne yazık ki çok sık söyleyebilirim ki, örneğin CICD'yi anlamak için yönetişim tarafında yeterince zaman harcamayan şirketler gördüm, çünkü bunun önemli olduğunu düşünmüyorlar. Ancak mikroservislerde olduğu gibi Micro-frontend için de otomasyonun doğru olması geliştirmeyi hızlandırmanızı sağlayacaktır. Otomasyon parçasına yeterince zaman harcamazsanız, faydadan çok yüke sahip olma riskiniz vardır.

Drew: Sanırım, web geliştirme dünyasında, insanların sorunu gerçekten anlamadan teknik bir çözüm bulma tehlikesiyle karşı karşıya olduğu pek çok şey gibi. Ve Mikro ön uç ile, sorunu görmeniz ve ardından hangi sorunu çözdüğünüzü bilmek için çözümü uygulamanız gereken bir durum gibi görünüyor. Sanırım Micro-frontend'in doğası, mevcut bir uygulamaya entegre etmeye başlamayı, küçük bir sorunu tespit etmeyi ve bu sorunu çözmek için bir Micro-frontend ile değiştirmeyi çok kolaylaştırıyor. Bu mantıklı bir öneri mi?

Luca: Evet, öyle derdim. Bu durumda, bu şekilde başlarsak önereceğim tek şey, yatay dilimleme yerine dikey dilimlemeye daha fazla bakmaktır, çünkü aksi takdirde çok fazla problem çözmeniz gerekiyor, diyelim ki örneğin Angular kullanıyorsunuz. ve Angular'ın yeni bir sürümüne geçmek istiyorsunuz. I-frame kullanmadan birlikte yaşayan iki Angular versiyonuna ihtiyacınız varsa, bu karmaşık olabilir veya mümkün olmayabilir. Dolayısıyla, başlarsanız, görünüşe göre değil ... zorluğu kontrol ederseniz, teknik açıdan değil, iş bakış açısından. Belki örneğin, farklı bir sürümle veya aynı sürümle ancak bir çerçevenin daha güncel sürümüyle yazmak istediğiniz oturum açma bölümünü, bilmiyorum, alabilirsin ve bu iyi bir yol olabilir. Ve sonra yoldan geçersiniz. Bu, belirli bir uygulamayı yavaş ama istikrarlı bir şekilde değiştirmenin iyi bir yolu olabilir.

Luca: Bizim durumumuzda yaptığımız şey, temel olarak mikro hizmetler için iyi bilinen bir model olan boğma düzenini uygulamak, ancak ön uçta. Yani URL'ye ve kullanıcının tarayıcısına ve ülkesine göre. O kadar yavaş ama istikrarlı, temelde monoliti öldürüyorduk, bu durumda tek sayfalı bir uygulamaydı, yeni uygulamamızı daha sık yayınlamak ve kullanıcıların davranışlarını görmek, deneyimi iyileştiriyorsa, sistemimizde herhangi bir soruna neden oluyordu. ya da değil. Bu, işe anında değer sağlamamıza izin verdi, ancak aynı zamanda varsayımlarımızı test etmemize ve doğru yöne gidip gitmediğimizi görmemize izin verdi.

Drew: Pek çok insanın karşılaştığı bazı sorunlara çok çekici bir çözüm gibi geliyor. Bir geliştirici olarak Micro-frontend hakkında daha fazla araştırmaya başlamak isteseydim, nereden başlamak iyi bir yer olurdu?

Luca: Evet, şu anda boş zamanımın çoğunu bu mimarileri savunmaya çalışarak geçiriyorum çünkü bence çok fazla yanlış anlama var. Medium hesabımda. Orada da mevcut olan birkaç makale yazdım. YouTube'da sorunsuz bir şekilde bulabileceğiniz konferanslarda çok sayıda video kaydetti. Ve bazı çerçeveler üzerinde bazı kod örnekleri arıyorsanız önereceğim diğer şey, tek bir SPA ile başlamanızı tavsiye ederim, çünkü esas olarak dikey dilimleme yaklaşımına sahiptir, onu almak daha kolaydır ve bu mimarinin faydasını anlamaya başlayabilirsiniz. Sonra mevcut olan birçok başka var. 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.