Obsah[Skrýt][Ukázat]
Myšlenka mikroslužeb si v poslední době získala velkou pozornost a mnoho firem ji využívá k odstranění velkých, monolitických backendů.
Jít stejnou cestou s frontendem je pro mnoho podniků stále výzvou, i když tento distribuovaný způsob konstrukce webových aplikací na straně serveru je z hlediska výzkumu a provádění víceméně spolehlivý.
Vzhledem ke své úzké závislosti monolit na straně klienta obvykle ztěžuje integraci nových funkcí, přijetí nových technologií a škálování jednotlivých komponent.
Tyto a další výzvy přiměly frontend vývojáře, aby prozkoumali používání mikroslužeb.
V důsledku toho byla vyvinuta zcela nová architektonická strategie známá jako mikro frontend pro vytváření front-end vrstvy webových stránek a webových aplikací.
Termín byl poprvé použit v roce 2016 a od té doby sklidil velkou pozornost pro dobrou věc.
Tento článek poskytne obecné informace o tom, co jsou mikro frontendy a jaké problémy řeší. funguje to, stejně jako klady a zápory.
Úvod do mikro front-end architektury
Současná metoda vývoje front-endu nazývaná mikro-frontendová architektura rozděluje a webové aplikace na malé, nezávislé části.
Pro koncového uživatele se tyto díly jeví jako jeden celek, i když byly zkonstruovány samostatně a poté složeny dohromady.
S tím rozdílem, že mikro frontendy se týkají klientské, nikoli serverové strany online řešení, jejich základní princip je stejný jako u mikroslužeb.
Vytváření sofistikovaných webových produktů dává největší smysl při použití mikro frontendového přístupu.
Mikro frontendy, na rozdíl od konvenčnějších front-endových monolitů, umožňují mnoha týmům samostatně spolupracovat na různých softwarových projektech.
Pomocí tohoto architektonického návrhu mohou programátoři vytvářet webové aplikace rychleji as větší škálovatelností a udržovatelností.
Zjednodušeně řečeno, každý mikro frontend je jen kus kódu pro odlišnou součást webové stránky.
Tyto funkce jsou řízeny samostatnými týmy, z nichž každý se specializuje na určité odvětví nebo cíl.
Monolitická vs Microservices vs Micro frontendová architektura
Myslete na stěhování. Bude pro vás jednodušší uspořádat vše do několika malých, odborně označených krabic a přemístit každou jednotlivě nebo zabalit celý personál do jedné obrovské krabice a převézt na nové místo?
Jednoznačné řešení existuje.
Tato analogie porovnává dvě odlišné architektury webových aplikací, monolity a mikroslužby (známé také jako mikro frontendy).
Monolitická architektura
Možná si budete moci vzpomenout na „staré dobré časy“, kdy byla vytvořena kompletní aplikace jako jeden, soudržný celek. Taková metoda se nazývá monolit, což je starý výraz pro velký kamenný blok.
To dává smysl.
Monolitické systémy mají vzájemně závislé prvky. Pokud tedy chcete něco upravit nebo přidat novou funkci, je možné, že se celý systém rozbije.
I když je zastaralý, občas stále existuje. Ano, jsme si vědomi vašeho současného vyjádření.
Koncepční rozdělení kódové základny na dvě různé komponenty – frontend (na straně klienta) a backend (na straně serveru) – se stalo nevyhnutelným, protože se vyvíjely nové technologie a softwarové produkty se komplikovaly.
Nejoblíbenějším způsobem provozu je nyní oddělení zájmů mezi prezentační vrstvou, se kterou koncový uživatel komunikuje, a vším, co se odehrává na pozadí.
Potřebuje dva týmy softwarového inženýrství, přičemž front-endový tým vytváří vizuální komponenty a back-endový tým vytváří webové služby, obchodní logiku, přístup k datům, integrace atd.
Navzdory tomuto oddělení však tato strategie stále zůstává svou povahou monolitická.
Hlavní změnou je, že nyní máme dva velké bloky kódu – frontend a backend – namísto jedné obrovské aplikace. Monolitické architektury nemusí být hrozné; mají několik výhod, včetně
- Jednoduchý a rychlý vývoj pro malé aplikace s jedinou zdrojovou kódovou základnou a velmi jednoduchým designem;
- Testování a ladění je velmi jednoduché, protože veškerý kód je na jednom místě, což týmu usnadňuje sledování toku požadavků a identifikaci chyb;
- Na začátku vývoje aplikace jsou náklady levnější, protože nevznikají náklady na infrastrukturu ani vývoj, dokud nejsou přidány nové funkce.
Nevýhody této strategie se odrážejí v
- Omezená flexibilita nasazení – týmy musí čekat, pokud na projektu pracuje jen hrstka z nich a při každé aktualizaci kódu je vyžadováno nové nasazení;
- Přijetí nových technologií je náročné, protože to vyžaduje přepsání významné části, ne-li celého projektu.
- Když se počet vývojářů zvyšuje, systém kódu se stává těsně propojeným, komplikovaným a obtížně ovladatelným a srozumitelným.
- Organizační problémy – každý člen týmu musí používat stejnou verzi knihoven a hlásit jakékoli změny, pokud mnoho týmů pracuje na monolitickém projektu.
- Obavy se škálovatelností – protože komponenty projektu jsou propojeny, představuje jejich samostatné škálování potíže, které mají za následek značné prostoje a vyšší výdaje.
- Složitá logika projektu může být pro nové členy týmu obtížné pochopit, zvláště pokud inženýři, kteří na něm původně pracovali, již nejsou zaměstnáni.
Rozvoj mikroslužeb a jejich blízkých příbuzných a mikrofrontendů řešil primární problémy s monolitickými systémy.
Architektura mikroslužeb
Architektonická metoda známá jako mikroslužby umožňuje vytvoření mnoha volně propojených a nezávisle nasazených menších komponent nebo služeb, které tvoří aplikační backend.
Každá služba má svou vlastní kódovou základnu, kanály CI/CD, procedury DevOps a procesy pro jejich spouštění.
Na obrázku výše můžete vidět, že monolitický backend tým je rozdělen do samostatných týmů.
Každý se individuálně zaměřuje na jiný aspekt aplikace (jako je produktová služba, vyhledávací služba a platební služba).
Komunikace mezi službami probíhá prostřednictvím zavedených protokolů známých jako API, jako je odlehčený protokol REST API, který používá synchronní vzory žádostí a odpovědí.
Další možností je využití asynchronní komunikace pomocí softwaru jako Kafka, který nabízí komunikační struktury a události publikovat/přihlašovat.
Mikroslužby se integrují s frontendem prostřednictvím backendu pro frontendovou službu (BFF) nebo API brány přes síť. BFF nabízí přizpůsobené API pro každého klienta, zatímco API brány poskytují jediný přístupový bod pro kolekci mikroslužeb.
Ale i s autonomními backendovými komponentami a všemi výhodami, které poskytují, je frontend stále monolit.
Proto jsou zde mikro frontendy užitečné.
Architektura mikro frontendů
Podobně jako u mikroslužeb, kde volně propojené komponenty spravuje několik týmů, mikrofrontendová architektura aplikuje tento koncept na prohlížeč.
Tato uživatelská rozhraní webových aplikací sledují tuto strukturu, která se skládá z poněkud autonomních komponent.
Týmy jsou také vytvářeny na základě potřeb klientů nebo případů použití spíše než podle konkrétních odborných znalostí nebo technologií.
V důsledku toho jsou týmy zapojeny do mikroslužeb a mikrofrontendových projektů.
- vertikálně rozdělené – protože na stejném projektu pracují také vývojáři frontendu, datoví experti, backendoví inženýři, QA inženýři atd., vytvářejí své funkce z Uživatelské rozhraní do databází; a
- mezifunkční – každý člen týmu přispívá svými odbornými znalostmi do skupiny.
Týmy si také mohou vybrat sadu technologií, která nejlépe vyhovuje jejich konkrétnímu oboru podnikání.
Jeden tým může použít React k naprogramování svého fragmentu. Jiný tým vytvoří novou verzi Angular. Jedním takovým příkladem je Vue.js.
Mikro rozhraní se používají ve spojení se souvisejícími mikroslužbami k řešení problémů, které mají vývojové týmy obvykle s monolity. Strategie nabízí následující výhody.
- Technologická svoboda: Inženýři frontendu si mohou vybrat alternativní rámce JavaScriptu, běhová prostředí a celé technologické sady v závislosti na potřebách společnosti. Kromě zastaralé architektury může být použit nový rámec.
- Je možný větší stupeň flexibility, protože každý mikrofrontend je samostatný a lze jej vyvíjet, testovat, nasazovat a upgradovat samostatně. Výsledkem je, že pokud jeden tým pracuje na funkci a provedl opravu chyby a jiný tým musí přidat svou vlastní funkci, nemusí čekat, až první tým dokončí svůj úkol.
- Autonomní týmy a systémy: Každý produktový tým a následně každá funkce může fungovat s malou závislostí na ostatních, což mu umožňuje pokračovat v práci, i když jsou blízké komponenty nedostupné.
- Vícenásobné menší kódové báze: Každý z mikrofrontendů bude mít svou vlastní, lépe ovladatelnou a menší kódovou základnu. Méně lidí se zaměří na konkrétní komponent uživatelského rozhraní, zjednoduší kontroly kódu a zlepší celkovou organizaci.
- Jednoduché škálování aplikací: Další výhodou mikro rozhraní je možnost škálovat každou funkci individuálně. Na rozdíl od monolitů, kde musí být celý program škálován pokaždé, když je přidána nová funkce, to činí celý proces efektivnější z hlediska času i peněz.
Jak funguje mikro frontend?
Jak jsme již uvedli, týmy jsou vertikálně organizovány uvnitř mikrofrontendové architektury, což znamená, že jsou odděleny znalostmi domény nebo účelem a jsou odpovědné od začátku do konce za konkrétní produkt.
Může mít jednu nebo dvě backendové mikroslužby a také malý frontend. Podívejme se podrobněji na charakteristiky tohoto vizuálního prvku, interakce s ostatními komponentami uživatelského rozhraní a začlenění do domovské stránky.
Mikro frontend může být
- celou stránku (např. stránku s podrobnostmi o produktu) nebo
- části stránky, které mohou používat jiné týmy, jako jsou záhlaví, zápatí a vyhledávací pole.
Velký web můžete rozdělit na několik druhů stránek a každý typ dát konkrétnímu personálu, aby na něm pracoval.
Na mnoha stránkách se však často vyskytuje několik komponent, jako jsou záhlaví, zápatí, bloky návrhů atd. Blok návrhu může být například zahrnut na domovské stránce, stránce s podrobnostmi o produktu nebo dokonce na stránce pokladny.
Týmy v podstatě mohou vytvářet dílky, které mohou ostatní týmy používat na svých stránkách.
Mikro rozhraní však lze nasadit samostatně jako různé projekty na rozdíl od opakovaně použitelných komponent.
To vše zní fantasticky, ale k vytvoření jednotného rozhraní se musí stránky a fragmenty nějak zkombinovat.
To vyžaduje integraci frontendu, kterou lze provést pomocí různých strategií, včetně směrování, kompozice a komunikace (viz obrázek výše).
Směrování
Když je pro přístup ke stránce vlastněné jiným týmem vyžadována služba ze stránky ovládané jedním týmem, je směrování užitečné pro integraci na úrovni stránky.
Každý mikro frontend je zpracován jako jednostránková aplikace. K zajištění směrování lze použít jednoduché odkazy HTML.
Uživatel může přinutit prohlížeč, aby stáhl cílové označení ze serveru a nahradil aktuální stránku novou, kliknutím na hypertextové odkazy.
Prostředí aplikace je naprosté minimum HTML, CSS a JavaScript, které pohání uživatelské rozhraní. I když data obsahu požadovaná ze serveru stále čekají, uživatel okamžitě obdrží statickou zobrazenou stránku. Centrální prostředí aplikace slouží jako nadřazená aplikace pro jednostránkové aplikace vytvořené různými týmy.
Bez ohledu na knihovnu nebo rámec, který se používá, meta-rámce umožňují sloučení různých stránek do jediné.
Složení
Kompozice je proces uspořádání kusů tak, aby se vešly do příslušných prostorů na stránce. Ve většině případů tým, který nasazuje stránku, okamžitě nenačte obsah fragmentu.
Místo toho umístí zástupný symbol nebo značku tam, kde by měl být fragment v označení.
Pomocí odlišného procesu skládání je dokončena konečná montáž. Složení lze rozdělit do dvou základních kategorií: na straně klienta a na straně serveru.
Složení na straně klienta: Webový prohlížeč se používá k vytváření a úpravě značek HTML. Každý mikro frontend má možnost změnit a zobrazit své označení odděleně od zbytku stránky.
Webové komponenty vám například umožňují provádět tento typ konstrukce.
Plánem je přeměnit každý fragment na webovou komponentu, kterou lze nezávisle nainstalovat jako soubor a.js, po kterém je mohou aplikace načíst a vykreslit v prostorech pro ně určených v rozložení motivu.
Webové komponenty jsou závislé na HTML a DOM API, které mohou používat jiné frontendové frameworky, a také na standardní metodě odesílání a přijímání dat prostřednictvím rekvizit a událostí.
Složení na straně serveru: S tímto designem jsou součásti uživatelského rozhraní kombinovány na serveru, což vede k odeslání kompletně vytvořené stránky na stranu klienta, což urychluje načítání.
Sestavení je často prováděno samostatnou službou, která je umístěna mezi webovým prohlížečem a webovými servery. CDN je jedna instance služby (síť pro doručování obsahu).
Můžete si vybrat jednu nebo kombinaci obou, v závislosti na vašich potřebách.
Mikrofrontendové komunikační vzorce
Architektura mikrofrontendu funguje nejlépe, když mezi různými komponentami nedochází k žádné nebo téměř žádné interakci. Mikrofrontendy občas potřebují spolu mluvit a sdílet informace. Zde je několik potenciálních vzorců, které k tomu mohou vést.
- Weboví pracovníci: Online pracovník je mechanismus, který umožňuje webovému obsahu spouštět JavaScript na pozadí, nezávisle na jiných skriptech a bez ovlivnění rychlosti stránky. Pro každou mikroaplikaci bude poskytnuto jedinečné pracovní API. Tato výhoda spočívá v tom, že časově náročnou práci lze provádět v jiném vlákně, což umožňuje vláknu uživatelského rozhraní pokračovat bez zpomalení nebo zastavení.
- Emitor událostí: V tomto případě mnoho komponent komunikuje mezi sebou tím, že naslouchá a reaguje na jakékoli změny stavu v komponentách, ke kterým jsou přihlášeny. Ostatní mikrofrontendy, které se přihlásily k odběru této konkrétní události, reagují, když mikrofrontend spustí tuto událost. To umožňuje emitor událostí, který byl zaveden do každého mikrofrontendu.
- Zpětná volání a rekvizity: V této části definujete nadřazenou komponentu a podřízené komponenty. Komunikace je organizována do stromové struktury. Nadřazené komponenty využívají rekvizity k přenosu dat jako funkcí dolů ve stromu komponent k podřízeným komponentám. Dítě může na oplátku účinně upozornit rodiče, když se v jeho stavu něco stane, tím, že odpoví na zpětná volání. React využívá tento režim.
Výhody Micro frontendu
Vývoj v rychle autonomních týmech
Nezávislý tým může vytvořit každou část webové aplikace nebo webu při použití mikro frontendové metody.
Každý tým je zcela autonomní, což znamená, že má na starosti celý vývojový cyklus komponent, od koncepce až po vydání a postprodukci.
Navíc to znamená, že různé týmy mohou hladce spolupracovat a současně pracovat na stejném projektu.
Uvolňovací cykly jsou proto podstatně rychlejší, než by tomu bylo u předních monolitů.
Menší kódové báze jednotlivých mikrofrontendů vedou k čistšímu kódu
Monolitické frontendy mají velké, nepraktické kódové základny, které se postupem času stávají stále chaotičtější a náročnější na správu.
Tento problém řeší mikro frontendy. Zdrojový kód každého mikro frontendu je lépe spravovatelný, protože je menší, jednodušší a kompaktnější.
Celkové webové řešení v důsledku toho těží z čistšího kódu.
Vylepšená stabilita aplikace díky volnému spojení
Webové řešení lze jen zřídkakdy rozdělit na zcela nezávislé části. V důsledku toho spolu mikrofrontendy mluví.
Každé spojení mezi komponentami je však významné i přes volnou konektivitu.
Selhání jedné komponenty má malý nebo žádný vliv na provoz všech ostatních komponent, což poskytuje zvýšenou stabilitu webového řešení.
Testování jednotlivých funkcí je jednodušší
Tato výhoda vyplývá z vlastností mikro frontendů. Na základě tohoto architektonického návrhu je klientská strana webového řešení modulární a každý modul je autonomní.
Výsledkem je, že hodnocení malé části uživatelského rozhraní samo o sobě je pro tým jednodušší než testování masivního monolitu.
Menší velikost balíku vede k rychlejšímu načítání stránky
Jednou z hlavních příčin zpožděného načítání v monolitických webových systémech bohatých na funkce je velikost balíčku JavaScriptu. Na druhé straně přístup mikro frontendu usnadňuje zkrácení doby načítání stránky.
Prohlížeč nemusí opakovaně stahovat nepotřebný kód, protože webová stránka se skládá z několika malých svazků. V důsledku toho se zvyšuje výkon stránky a doba načítání.
Technologická nezávislost
Násobek front-end frameworky mohou vývojáři použít k vytvoření jediného online řešení s mikrofrontendovou architekturou.
Protože je každá součást autonomní, lze ji zkonstruovat pomocí technologie, která nejlépe vyhovuje úkolům týmu.
Přirozeně by programátoři měli být opatrní při výběru frameworků pro softwarový projekt, který mají na starosti, a konzultace s ostatními týmy stále důrazně doporučujeme.
Je však nulová šance, že budete nuceni používat starší rámec po dobu životnosti aplikace.
Nevýhody Micro Frontendu
Komplexní testování webových řešení v plném rozsahu
Testování různých modulů webového řešení je snadné, když používá mikrofrontendovou architekturu. Liší se však od hodnocení webové aplikace jako celku.
Než budete pokračovat, ověřte, že všechny díly fungují tak, jak bylo zamýšleno. To může být obtížné, protože mikrofrontendy fungují nezávisle a mají samostatné procesy doručování.
Drahé počáteční investice
Vývoj mikrofrontendu obvykle vyžaduje značné finanční výdaje. Je nákladné sestavit a udržovat mnoho předních týmů.
Kromě toho budete potřebovat vedoucí pracovníky, kteří budou organizovat práci, zajistit, aby bylo vše koordinované a zaručit vynikající týmovou komunikaci.
Složitost vývoje a nasazení
Postupy vývoje a nasazení se mohou stát komplikovanějšími v důsledku návrhu mikrofrontendu.
Nezávislé vývojové týmy pracující na stejném projektu by například mohly řešení zahltit příliš mnoha komponentami, což by mohlo způsobit problémy ve fázi nasazení.
Správná montáž všech modulů a jejich plynulá integrace do celkového schématu také není vždy jednoduchá; tato práce obvykle vyžaduje důkladné pochopení všech závislostí.
Problémy se zachováním koherence v uživatelské zkušenosti
Udržování konzistentního uživatelského rozhraní je náročné, když týmy pracují odděleně na několika částech softwaru.
Webové řešení by měli sdílet všichni vývojáři projektu. V opačném případě může být na silnici spousta rozporů.
Proč investovat do čističky vzduchu?
Mikro frontendy, moderní architektonický design, mohou výrazně zvýšit výkon rozsáhlých projektů vývoje webu založených na mikroslužbách.
Umožňuje programátorům rozdělit kompletní řešení do samostatných částí, které může vytvořit několik autonomních týmů. Z toho plynou četné výhody, včetně rychlejšího zavádění funkcí, snadnějšího testování jednotlivých modulů a bezproblémovějších upgradů.
Existují však také určité potíže s mikro frontendy.
Například komplexní testování aplikace může být náročné.
Navíc, protože je potřeba velký tým inženýrů a administrátorů, jsou mikro frontend projekty velmi nákladné.
Než se tedy rozhodnete, musíte vzít v úvahu všechny složky vašeho obchodního případu.
Vladimír Čamaj
Nějak jsem nepochopil, na jakém principu funguje komunikace mezi jednotlivými komponentami na frontendu. Nechápu, jak chcete propojovat komponenty, které jsou vytvořeny v různých frameworkech. V článku o tom nic není. Systém akcí a posluchačů mi připadá jako peklo na zemi. Jak si to máme představit?