Mikro Ön Uçların Güçlü Yönleri ve Faydaları

Yayınlanan: 2022-03-11

Mikro ön uç mimarisi, bir ön uç uygulamasının gevşek bir şekilde birlikte çalışan bireysel, yarı bağımsız "mikro uygulamalara" ayrıldığı bir tasarım yaklaşımıdır. Mikro ön uç konsepti, belli belirsiz bir şekilde mikro hizmetlerden esinlenmiş ve adını almıştır.

Mikro ön uç modelinin faydaları şunları içerir:

  1. Mikro ön uç mimarileri daha basit olabilir ve bu nedenle akıl yürütmesi ve yönetmesi daha kolay olabilir.
  2. Bağımsız geliştirme ekipleri, bir ön uç uygulaması üzerinde daha kolay işbirliği yapabilir.
  3. Yan yana çalışan "yeni" bir uygulamaya sahip olarak "eski" bir uygulamadan geçiş yapmak için bir araç sağlayabilirler.

Mikro ön uçlar son zamanlarda çok dikkat çekiyor olsa da, henüz tek bir baskın uygulama ve net bir “en iyi” mikro ön uç çerçevesi yoktur. Aslında, amaçlara ve gereksinimlere bağlı olarak çeşitli yaklaşımlar vardır. Daha iyi bilinen uygulamalardan bazıları için kaynakçaya bakın.

Bu yazıda, mikro önyüzler teorisinin çoğunu atlayacağız. Burada ele almayacağız :

  • Bir uygulamayı mikro uygulamalara "dilimleme"
  • Mikro ön uçların bir CI/CD modeline nasıl uyduğu dahil dağıtım sorunları
  • Test yapmak
  • Mikro uygulamaların, arka uçtaki mikro hizmetlerle bire bir hizada olması gerekip gerekmediği
  • Mikro ön uç kavramının eleştirileri
  • Mikro ön uçlar ve sade bir eski bileşen mimarisi arasındaki fark

Bunun yerine, somut bir uygulamaya odaklanan, mikro ön uç mimarisindeki önemli sorunları ve bunların olası çözümlerini vurgulayan bir mikro önyüz öğreticisi sunacağız.

Uygulamamızın adı Yumcha. Kantonca'daki "yum cha"nın gerçek anlamı "çay içmek"tir, ancak günlük anlamı "dim sum için dışarı çıkmak"tır. Buradaki fikir, bir makro uygulama içindeki bireysel mikro uygulamaların (oluşturulmuş, üst düzey uygulama diyeceğimiz gibi), dim sum bir öğle yemeğinde getirilen çeşitli lokma büyüklüğünde porsiyon sepetlerine benzer olmasıdır.

Yukarıda açıklandığı gibi örnek bir mikro ön uç tabanlı uygulamaya genel bakış.

Bazen Yumcha'ya "mikro ön uç çerçevesi" olarak atıfta bulunacağız. Günümüz dünyasında "çerçeve" terimi genellikle web uygulamaları için Angular, React, Vue.js veya diğer benzer üst yapılara atıfta bulunmak için kullanılır. Bu anlamda bir çerçeveden hiç bahsetmiyoruz. Yumcha'yı sadece kolaylık olsun diye bir çerçeve olarak adlandırıyoruz: Aslında daha çok mikro ön uç tabanlı uygulamalar oluşturmak için bir dizi araç ve birkaç ince katmandan oluşuyor.

Mikro ön uç Eğitimi İlk Adımları: Oluşturulmuş Bir Uygulama için İşaretleme

Bir makro uygulamayı ve onu oluşturan mikro uygulamaları nasıl tanımlayabileceğimizi düşünerek konuya girelim. İşaretleme her zaman web'in merkezinde olmuştur. Bu nedenle makro uygulamamız, bu işaretlemeden daha karmaşık bir şey tarafından belirtilmeyecektir:

 <html> <head> <script src="/yumcha.js"></script> </head> <body> <h1>Hello, micro-frontend app.</h1> <!-- HERE ARE THE MICROAPPS! --> <yumcha-portal name="microapp1" src="https://microapp1.example.com"></yumcha-portal> <yumcha-portal name="microapp2" src="https://microapp2.example.com"></yumcha-portal> </body> </html>

Makro uygulamamızı işaretleme kullanarak tanımlamak, mikro uygulamalarımızı düzenlemek ve yönetmek için bize HTML ve CSS'nin gücüne tam erişim sağlar. Örneğin, bir mikro uygulama diğerinin üstüne veya yanına oturabilir veya sayfanın köşesinde olabilir veya bir akordeon bölmesinde olabilir veya bir şey olana kadar gizli kalabilir veya kalıcı olarak arka planda kalabilir. .

Mikro uygulamalar için kullanılan özel öğeyi <yumcha-portal> olarak adlandırdık, çünkü "portal", mikro ön uçlarda kullanım için standart bir HTML öğesi tanımlamaya yönelik erken bir girişim olan portal teklifinde kullanılan mikro uygulamalar için umut verici bir terimdir.

<yumcha-portal> Özel Öğesini Uygulama

<yumcha-portal> nasıl uygulamalıyız? Tabii ki bir web bileşeni olarak özel bir öğe olduğundan! Mikro ön uç web bileşenlerini yazmak ve derlemek için bir dizi güçlü yarışmacı arasından seçim yapabiliriz; burada Polimer Projesinin en son yinelemesi olan LitElement'i kullanacağız. LitElement, bizim için özel öğe ortak bilgilerinin çoğunu işleyen TypeScript tabanlı sözdizimsel şekeri destekler. <yumcha-portal> sayfasını sayfamızda kullanılabilir hale getirmek için yukarıda yaptığımız gibi ilgili kodu <script> olarak eklememiz gerekiyor.

Ama <yumcha-portal> gerçekte ne yapar? İlk yaklaşım, belirtilen kaynakla yalnızca bir iframe oluşturması olacaktır:

 render() { return html`<iframe src=${this.src}></iframe>`; }

...burada render , html etiketli şablon değişmezini kullanan standart LitElement oluşturma kancasıdır. Bu minimal işlevsellik, bazı önemsiz kullanım durumları için neredeyse yeterli olabilir.

Mikro uygulamaları iframe s'ye gömme

iframe s, herkesin nefret etmeyi sevdiği HTML öğesidir, ancak aslında son derece kullanışlı, kaya gibi sağlam korumalı alan davranışı sağlarlar. Bununla birlikte, iframe s kullanırken dikkat edilmesi gereken ve uygulamamızın davranışı ve işlevselliği üzerinde potansiyel etkisi olan uzun bir sorun listesi var:

  • İlk olarak, iframe kendilerini nasıl boyutlandırdıkları ve düzenledikleri konusunda iyi bilinen tuhaflıkları vardır.
  • CSS elbette daha iyi veya daha kötüsü için iframe tamamen izole edilecektir.
  • Tarayıcının "geri" düğmesi oldukça iyi çalışacaktır, ancak iframe mevcut gezinme durumu sayfanın URL'sine yansıtılmayacak , bu nedenle ne oluşturulmuş uygulamanın aynı durumuna ulaşmak için URL'leri kesip yapıştırabildik ne de derin bağlantı onlara.
  • CORS kurulumumuza bağlı olarak, iframe ile dışarıdan iletişimin postMessage protokolünden geçmesi gerekebilir .
  • iframe sınırları boyunca kimlik doğrulama için düzenlemeler yapılması gerekecektir.
  • Bazı ekran okuyucular iframe sınırında takılabilir veya kullanıcıya duyurabilecekleri bir başlığa sahip olmak için iframe ihtiyaç duyabilir.

Bu sorunlardan bazıları, makalenin ilerleyen bölümlerinde tartışacağımız bir alternatif olan iframe s kullanılmayarak önlenebilir veya hafifletilebilir.

Artı tarafta, iframe kendi bağımsız Content-Security-Policy (CSP) olacaktır. Ayrıca, iframe işaret ettiği mikro uygulama bir hizmet çalışanı kullanıyorsa veya sunucu tarafında işleme uyguluyorsa, her şey beklendiği gibi çalışacaktır. Üst çerçeveye gitme gibi yeteneklerini sınırlamak için iframe çeşitli korumalı alan seçenekleri de belirtebiliriz.

Bazı tarayıcılar, iframe s için, kullanıcı yanlarına gelene kadar ekranın alt kısmındaki iframe 'lerin yüklenmesini erteleyen bir loading=lazy özniteliği gönderdi veya göndermeyi planlıyor, ancak bu, tembel yüklemenin ayrıntılı kontrolünü sağlamaz. istiyoruz.

iframe s ile ilgili asıl sorun, iframe içeriğinin alınması için birden fazla ağ isteği almasıdır. En üst düzey index.html alınır, komut dosyaları yüklenir ve HTML'si ayrıştırılır; ancak daha sonra tarayıcının iframe için başka bir istek başlatması, onu almayı beklemesi, komut dosyalarını ayrıştırması ve yüklemesi ve iframe içeriği. Çoğu durumda, iframe JavaScript'inin yine de dönmesi, kendi API çağrılarını yapması ve anlamlı verileri yalnızca bu API çağrıları geri döndükten ve veriler görüntülenmek üzere işlendikten sonra göstermesi gerekir.

Bu, özellikle birkaç mikro uygulama söz konusu olduğunda, büyük olasılıkla istenmeyen gecikmelere ve oluşturma yapaylıklarına neden olacaktır. iframe uygulaması SSR'yi uygularsa, bu yardımcı olur, ancak yine de ek gidiş-dönüş gerekliliğini ortadan kaldırmaz.

Dolayısıyla, portal uygulamamızı tasarlarken karşılaştığımız en önemli zorluklardan biri, bu gidiş-dönüş sorunuyla nasıl başa çıkacağımızdır. Amacımız, tek bir ağ isteğinin, her birinin önceden doldurabileceği içerik de dahil olmak üzere, tüm mikro uygulamalarıyla tüm sayfayı indirmesidir. Bu sorunun çözümü Yumcha sunucusunda yatmaktadır.

Yumcha Sunucusu

Burada sunulan mikro ön uç çözümünün önemli bir unsuru, mikro uygulama kompozisyonunu işlemek için özel bir sunucu kurmaktır. Bu sunucu, istekleri her bir mikro uygulamanın barındırıldığı sunuculara proxy ile gönderir. Elbette, bu sunucuyu kurmak ve yönetmek biraz çaba gerektirecektir. Bazı mikro ön uç yaklaşımları (örneğin, tek spa), dağıtım ve yapılandırma kolaylığı adına bu tür özel sunucu kurulumlarına olan ihtiyacı ortadan kaldırmaya çalışır.

Ancak, bu ters proxy'yi kurmanın maliyeti, elde ettiğimiz faydalarla dengelenmekten daha fazladır; aslında, mikro ön uç tabanlı uygulamaların, onsuz başaramayacağımız önemli davranışları vardır. Böyle bir ters proxy kurmanın birçok ticari ve ücretsiz alternatifi vardır.

Ters proxy, mikro uygulama isteklerini uygun sunucuya yönlendirmenin yanı sıra, makro uygulama isteklerini de bir makro uygulama sunucusuna yönlendirir. Bu sunucu, oluşturulan uygulama için HTML'yi özel bir şekilde hazırlar. http://macroapp.example.com gibi bir URL'de proxy sunucusu aracılığıyla tarayıcıdan index.html için bir istek aldığında, index.html dosyasını alır ve geri dönmeden önce onu basit ama önemli bir dönüşüme tabi tutar. o.

Özellikle, HTML, Node.js ekosisteminde bulunan yetkin HTML ayrıştırıcılarından biriyle kolayca yapılabilen <yumcha-portal> etiketleri için ayrıştırılır. <yumcha-portal> için src özniteliği kullanılarak, mikro uygulamayı çalıştıran sunucuyla bağlantı kurulur ve varsa, sunucu tarafında oluşturulmuş içerik de dahil olmak üzere index.html dosyası alınır. Sonuç, tarayıcı tarafından yürütülmemesi için HTML yanıtına bir <script> veya <template> etiketi olarak eklenir.

Yumcha'nın sunucu mimarisinin çizimi. Tarayıcı, ters proxy ile iletişim kurar, bu da makro uygulama ve her bir mikro uygulama ile iletişim kurar. Macroapp adımı, uygulamanın ana index.html dosyasını dönüştürür ve önceden doldurur.

Bu kurulumun avantajları, her şeyden önce, oluşturulmuş sayfa için index.html için ilk istekte, sunucunun, eğer varsa, SSR ile oluşturulmuş içerik dahil olmak üzere, ayrı ayrı mikro uygulama sunucularından ayrı sayfaları tamamen alabilmesidir. herhangi biri—ve iframe ek sunucu gidiş dönüşleri olmadan doldurmak için kullanılabilecek içerik de dahil olmak üzere tarayıcıya tek, eksiksiz bir sayfa teslim edin (az kullanılan srcdoc niteliğini kullanarak). Proxy sunucusu ayrıca mikro uygulamaların nereden sunulduğuna dair tüm ayrıntıların meraklı gözlerden gizlenmesini sağlar. Son olarak, uygulama isteklerinin tümü aynı kaynaktan yapıldığından CORS sorunlarını basitleştirir.

İstemciye geri dönersek, <yumcha-portal> etiketi somutlaştırılır ve sunucu tarafından yanıt belgesine yerleştirildiği içeriği bulur ve uygun zamanda iframe işler ve içeriği srcdoc özniteliğine atar. Eğer iframe s kullanmıyorsak (aşağıya bakın), o zaman bu <yumcha-portal> etiketine karşılık gelen içerik, bunu kullanıyorsak özel öğenin gölge DOM'sine veya doğrudan belgede satır içine eklenir.

Bu noktada, zaten kısmen çalışan bir mikro ön uç tabanlı uygulamamız var.

Bu, Yumcha sunucusu için ilginç işlevsellik açısından buzdağının sadece görünen kısmı. Örneğin, mikro uygulama sunucularından gelen HTTP hata yanıtlarının nasıl işlendiğini veya çok yavaş yanıt veren mikro uygulamalarla nasıl başa çıkılacağını kontrol etmek için özellikler eklemek isteriz; bir mikro uygulama çalışmıyorsa, sayfayı sunmak için sonsuza kadar beklemek istemiyoruz. tepki vermek! Bunları ve diğer konuları başka bir yazıya bırakacağız.

Yumcha macroapp index.html dönüştürme mantığı, sunucusuz bir lambda işlevi tarzında veya Express veya Koa gibi sunucu çerçeveleri için ara yazılım olarak kolayca uygulanabilir.

Saplama Tabanlı Mikro Uygulama Kontrolü

İstemci tarafına dönersek, mikro uygulamaları nasıl uyguladığımızın verimlilik, gecikmeli yükleme ve sorunsuz oluşturma için önemli olan başka bir yönü daha vardır. Her mikro uygulama için iframe etiketini, başka bir ağ isteği yapan bir src özniteliği ile veya sunucu tarafından bizim için doldurulan içerikle doldurulmuş srcdoc özniteliği ile oluşturabiliriz. Ancak her iki durumda da, tüm komut dosyası ve bağlantı etiketlerinin yüklenmesi, önyükleme ve ilk API çağrıları ve ilgili veri işleme dahil olmak üzere, bu iframe kod, kullanıcı söz konusu mikro uygulamaya hiç erişmese bile hemen başlayacaktır.

Bu soruna bizim çözümümüz, başlangıçta sayfadaki mikro uygulamaları, daha sonra etkinleştirilebilecek küçük, devre dışı bırakılmış taslaklar olarak göstermektir. Etkinleştirme, az kullanılan IntersectionObserver API'sini kullanarak mikro uygulamanın bölgesinin görüntülenmesiyle veya daha yaygın olarak dışarıdan gönderilen ön bildirimlerle gerçekleştirilebilir. Tabii ki microapp'ın hemen aktif hale getirilmesini de belirtebiliriz.

Her durumda, yalnızca mikro uygulama etkinleştirildiğinde iframe gerçekten oluşturulur ve kodu yüklenir ve yürütülür. LitElement kullanarak uygulamamız açısından ve etkinleştirme durumunun activated bir örnek değişkeni tarafından temsil edildiğini varsayarsak, şöyle bir şeye sahip oluruz:

 render() { if (!this.activated) return html`{this.placeholder}`; else return html` <iframe srcdoc="${this.content}" @load="${this.markLoaded}"></iframe>`; }

Mikrouygulamalar Arası İletişim

Bir makro uygulamayı oluşturan mikro uygulamalar tanım gereği gevşek bir şekilde bağlı olsa da, yine de birbirleriyle iletişim kurabilmeleri gerekir. Örneğin, bir navigasyon mikro uygulamasının, kullanıcı tarafından henüz seçilen başka bir mikro uygulamanın etkinleştirilmesi gerektiğine ve etkinleştirilecek uygulamanın bu tür bildirimleri alması gerektiğine dair bir bildirim göndermesi gerekir.

Minimalist zihniyetimize uygun olarak, çok sayıda mesaj ileten makineyi tanıtmaktan kaçınmak istiyoruz. Bunun yerine, web bileşenlerinin ruhuna uygun olarak DOM olaylarını kullanacağız. Yaklaşan bir olayın tüm taslaklarını önceden bildiren, o olay türü için etkinleştirilme talebinde bulunan herhangi bir olayı bekleyen ve ardından herhangi bir mikro uygulamanın dinleyebileceği belgeye karşı olayı gönderen önemsiz bir yayın API'sı sağlıyoruz. o. Tüm iframe 'lerimizin aynı kökenli olduğu göz önüne alındığında, olayları tetikleyecek öğeleri bulmak için iframe sayfaya ve tam tersine ulaşabiliriz.

yönlendirme

Bu gün ve çağda, hepimiz SPA'lardaki URL çubuğunun uygulamanın görünüm durumunu temsil etmesini beklemeye başladık, böylece doğrudan uygulama içindeki bir sayfaya atlamak için kesebilir, yapıştırabilir, postalayabilir, metin gönderebilir ve bağlantı kurabiliriz. Bununla birlikte, bir mikro ön uç uygulamasında, uygulama durumu aslında her bir mikro uygulama için bir tane olmak üzere durumların bir birleşimidir. Bunu nasıl temsil edip kontrol edeceğiz?

Çözüm, her bir mikro uygulamanın durumunu tek bir bileşik URL'ye kodlamak ve bu bileşik URL'yi nasıl bir araya getirip ayıracağını bilen küçük bir makro uygulama yönlendiricisi kullanmaktır. Ne yazık ki, bu, her mikro uygulamada Yumcha'ya özgü mantık gerektirir: makro uygulama yönlendiricisinden mesajlar almak ve mikro uygulamanın durumunu güncellemek ve tersine, bileşik URL'nin güncellenebilmesi için makro uygulama yönlendiricisine bu durumdaki değişiklikleri bildirmek. Örneğin, Angular için bir YumchaLocationStrategy veya React için bir <YumchaRouter> öğesi hayal edilebilir.

Bir makro uygulama durumunu temsil eden bileşik bir URL. Sorgu dizesi, daha sonra kimlikleri anahtarları olarak belirtilen mikro uygulamalara iletilecek olan iki ayrı (çift kodlanmış) sorgu dizesinin kodunu çözer.

iframe Dışı Durum

Yukarıda belirtildiği gibi, mikro uygulamaları iframe s'de barındırmanın bazı dezavantajları vardır. İki alternatif vardır: bunları doğrudan sayfanın HTML'sine satır içi ekleyin veya gölge DOM'ye yerleştirin. Her iki alternatif de iframe artılarını ve eksilerini bir şekilde yansıtır, ancak bazen farklı şekillerde.

Örneğin, bireysel mikro uygulama CSP ilkelerinin bir şekilde birleştirilmesi gerekir. Gölge DOM'yi desteklediklerini varsayarsak, ekran okuyucular gibi yardımcı teknolojiler iframe s'den daha iyi çalışmalıdır (hepsi henüz desteklememektedir). Uygulamanın hizmet çalışanının "/" değil, uygulamanın adı altında kayıtlı olduğundan emin olması gerekmesine rağmen, bir mikro uygulamanın hizmet çalışanlarını "kapsam" olarak adlandırılan hizmet çalışanı kavramını kullanarak kaydettirmek için düzenleme yapmak kolay olmalıdır. iframe ile ilişkili düzen sorunlarının hiçbiri satır içi veya gölge DOM yöntemleri için geçerli değildir.

Ancak, Angular ve React gibi çerçeveler kullanılarak oluşturulan uygulamalar, büyük olasılıkla satır içi veya gölge DOM'da yaşamaktan mutsuz olacaktır. Bunlar için muhtemelen iframe s kullanmak isteyeceğiz.

Satır içi ve gölge DOM yöntemleri, CSS söz konusu olduğunda farklılık gösterir. CSS, gölge DOM'de temiz bir şekilde kapsüllenecektir. Herhangi bir nedenle CSS'yi gölge DOM ile paylaşmak isteseydik, yapılandırılabilir stil sayfaları veya benzeri bir şey kullanmamız gerekirdi. Satır içi mikro uygulamalarla, tüm CSS sayfa boyunca paylaşılacaktır.

Sonunda, <yumcha-portal> içindeki satır içi ve gölge DOM mikro uygulamaları için mantığı uygulamak basittir. Belirli bir mikro uygulama için içeriği, sunucu mantığı tarafından bir HTML <template> öğesi olarak sayfaya eklendiği yerden alırız, kopyalarız, ardından normalde öğenin gölge renderRoot olan ancak ayrıca satır içi (gölge olmayan DOM) durumu için öğenin kendisine ( this ) ayarlanmalıdır.

Fakat bekle! Mikro uygulama sunucusu tarafından sunulan içerik, tam bir HTML sayfasıdır. Mikro uygulama için html , head ve body etiketleriyle tamamlanmış HTML sayfasını makro uygulama sayfasının ortasına ekleyemiyoruz, değil mi?

Bu sorunu, mikro uygulama sunucusundan alınan mikro uygulama içeriğinin sarıldığı template etiketinin bir tuhaflığından yararlanarak çözüyoruz. Modern tarayıcılar bir template etiketiyle karşılaştığında, onu "yürütmeseler" de, onu ayrıştırırlar ve bunu yaparken <html> , <head> ve <body> etiketleri gibi geçersiz içeriği kaldırırlar. , iç içeriğini korurken. Böylece <head> içindeki <script> ve <link> etiketleri ile <body> içeriği korunur. Sayfamıza mikro uygulama içeriği eklemek için tam olarak istediğimiz şey budur.

Mikro ön uç Mimarisi: Şeytan Ayrıntılarda Gizlidir

Mikro ön uçlar, (a) daha iyi bir mimari yaklaşım olduğu ortaya çıkarsa ve (b) günümüz web'inin sayısız pratik gereksinimlerini karşılayacak şekilde nasıl uygulanacağını bulabilirsek, webapp ekosisteminde kök salacaktır.

İlk soru açısından, hiç kimse mikro ön uçların tüm kullanım durumları için doğru mimari olduğunu iddia etmez. Özellikle, tek bir ekibin sıfırdan geliştirme geliştirmesinin mikro ön uçları benimsemesi için çok az neden olacaktır. Ne tür bağlamlarda ne tür uygulamaların bir mikro ön uç modelinden en çok fayda sağlayabileceği sorusunu diğer yorumculara bırakacağım.

Uygulama ve fizibilite açısından, bu makalede bahsedilmeyen birkaçı da dahil olmak üzere, özellikle kimlik doğrulama ve güvenlik, kod çoğaltma ve SEO dahil olmak üzere, ilgilenilmesi gereken çok sayıda ayrıntı olduğunu gördük. Bununla birlikte, bu makalenin, daha fazla iyileştirme ile gerçek dünya gereksinimlerine dayanabilecek mikro ön uçlar için temel bir uygulama yaklaşımı ortaya koyduğunu umuyorum.

bibliyografya

  • Mikro Ön Uçlar — Açısal Stilde Yapmak — Bölüm 1
  • Mikro Ön Uçlar — Açısal Stilde Yapmak — Bölüm 2
  • Mikro ön uçlar kullanarak bir AngularJS uygulamasını geliştirme
  • Mikro Ön Yüzler
  • UI mikro hizmetleri — anti-kalıpın tersine çevrilmesi (mikro ön uçlar)
  • UI mikro hizmetleri — bir anti-kalıp mı?
  • Micro-Frontends kullanarak Sayfa Oluşturma, şiddetle tavsiye ettiğim ters proxy ve SSI'lerin Yumcha benzeri bir yaklaşımını benimser.
  • Mikro ön uç kaynakları
  • Podyum
  • Mikro Ön Yüzleri Anlamadım. Bu, mikro ön uç mimarilerinin türleri ve kullanım durumları hakkında oldukça iyi bir genel bakıştır.
  • Vue.js, AWS Lambda ve Hypernova kullanan Sunucusuz Mikro ön uçlar
  • Mikro Ön Uçlar: Harika, kapsamlı bir genel bakış.