Micro Frontends – používání přístupu microservices při frontend vývoji

Architektura se začala hlouběji diskutovat a analyzovat kolem roku 2015. V roce 2016 byla její idea představena v Technology radar.

Idea vychází z architektury Microservices, která popisuje způsob, jak rozdělit monolitický backend na víc menších logických celků, které spolu navzájem spolupracují. Jednou z prvních větších firem, které se rozhodly architekturu micro frontends (MFE) použít, byla Ikea. Později se tento koncept osvědčil a využily ho i další firmy, například DAZN, Spotify, Soundcloud, Zalando aj.

Jakým výzvám mohou týmy čelit u velkých projektů? Například:

• narůstající komplexnost aplikace,
• organizační problémy,
• pomalý onboarding nových členů týmu,
• škálovatelnost,
• rychlost dodávání inovací do aplikace,
• nezávislý deployment.

Koncept architektury

Příkladem aplikace, která zahrnuje několik funkčních částí, může být web banky. Zahrnuje např. klientskou zónu, internetové bankovnictví, mediální sekci, sekci pro investory atd. Každá z uvedených částí představuje logický celek, který by mohl existovat jako samostatná aplikace. Myšlenkou MFE je rozdělit velkou komplexní webovou aplikaci (např. Single Page Application) na menší logické celky, které spolu komunikují a spolupracují. Tyto celky představují samostatné subaplikace (SubApp). Cílem je dosáhnout nízké míry vzájemné závislosti mezi SubApps a snažit se o co největší izolovanost a logickou celistvost.

Výhody MFE

Možnost použití různých technologií pro každou SubApp:

• volnost při implementaci pomocí frameworku, např. React, Angular, Vue…
• vlastní koncept pro stylování: Sass, Scss, StyledComponents, Tailwind, Bootstrap…
• volba jazyka, ve kterém bude kód napsaný, např. Javascript nebo Typescript

Autonomní týmy – každou SubApp může vyvíjet jiný tým vývojářů, který si nezávisle na ostatních týmech nastaví vlastní procesy, konvence, postupy atd. Jejich fungování není přímo ovlivněno jiným týmem. To zahrnuje nezávislost při vývoji, nasazení a managementu.

Izolace chybových stavů – pokud dojde k selhání jedné SubApp, neovlivní to ostatní a aplikace jako celek bude fungovat i nadále.

Rychlejší onboarding – nový člen týmu bude pracovat na vývoji SubApp, jejíž komplexnost je mnohem menší ve srovnání s celou aplikací, pokud by byla stavěná jako monolit. Nemusí tedy znát všechny uživatelské scénáře, vazby mezi logickými bloky ani celkovou myšlenku.

Možnosti HR při náboru – navazuje přímo na první uvedenou výhodu. Pokud není aplikace striktně postavena jen na jediném frameworku, není třeba se při hledání nových lidí pro projekt zaměřovat striktně na jedinou technologii. V projektu tak najdou uplatnění lidé s různými technologickými znalostmi: vývojář v Reactu, vývojář v Angularu…

Vývoj inovací a nových funkcionalit do budoucna – vzhledem ke slabé vzájemné provázanosti jednotlivých SubApps jsou změna/vylepšení/rozšíření stávající implementace méně náročné. Nedopadají totiž na celou aplikaci, ale pouze na konkrétní SubApp.

Nevýhody MFE

Konzistentnost UX/UI – je nutné zachovat jednotný design a UX flow v celé aplikaci, aby působila jako jeden celek.

Duplicita kódu – větší pravděpodobnost opakování částí kódu, které řeší stejný problém, napříč jednotlivými SubApps.

Technologické problémy – správné nastavení celého projektu, vzájemné propojení SubApps, debugging a monitoring, používání stejného názvosloví pro globální proměnné, override CSS stylů… To všechno jsou výzvy, kterým je třeba při použití architektury MFE čelit. V zájmu úspěšného použití je nutná i nemalá znalost jednotlivých technologií a samotné architektury.

Testování – jednodušší z pohledu SubApp, ale náročnější z pohledu aplikace jako celku. Je potřeba testovat nejen jednotlivé SubApps, ale taky jednotlivé integrace mezi nimi.

Náročnější analýza – správné určení logického rozsahu a toho, co konkrétně má daná SubApp pokrývat. Také komunikační rozhraní mezi jednotlivými SubApps musí být univerzální, jednoduché a nesmí si vynucovat silné závislosti a provázanost jednotlivých částí.

Typy integrací

Základem celé aplikace postavené na architektuře MFE je kontejner. Jedná se o řídicí prvek, který rozhoduje o tom, kdy a kde se má daná SubApp zobrazit.

Integrace – jak a kdy kontejner získá přístup ke zdrojovým kódům jednotlivých SubApps.

Existují 3 typy integrací, kdy se jednotlivé SubApps vzájemně propojují s kontejnerem a vytvoří funkční celek.

Build-time (compile-time)

Před načtením kontejneru v prohlížeči získá kontejner přístup ke zdrojovému kódu požadované SubApp.

Jednotlivé SubApps jsou integrované do kontejneru jako moduly (závislosti). Build SubApp vytvoří modul, který se zahrne do kontejneru a je obsažený v jeho výsledném buildu. Změna v SubApp způsobí, že je vyžadovaný další build a nasazení kontejneru s novou verzí SubApp.

Integraci je snadné nastavit a porozumět jí. Nevýhodou je opětovný deploy kontejneru při každé změně (verzi) SubApp, kterou chceme reflektovat ve finální aplikaci. Taky láká na pevné propojení kontejner + SubApp(s).

Run-time (client-side)

Po načtení kontejneru do prohlížeče získá přístup ke zdrojovému kódu požadované SubApp.

Jednotlivé SubApps běží samostatně vzdáleně na definované cestě. Kontejner má definované, na jaké cestě je jaká SubApp dostupná. Změna verze SubApp nevyžaduje redeploy kontejneru a reflektuje se okamžitě. Různé verze SubApp mohou mít definovány různé cesty.

Integrace je složitější na setup, ale nevyžaduje dodatečný deploy kontejneru při změně SubApp. I deploy samotné SubApp je nezávislý.

Server (Server side rendering)

Během renderování kontejneru server rozhodne, zda má, nebo nemá být zahrnut zdrojový kód požadované SubApp.

Ukládá zdrojové kódy SubApps do CDN a skládá je do konečného zobrazení, které se později zobrazí během build-time nebo run-time. Principy jsou dále podobné v závislosti na tom, kdy je výsledné zobrazení zobrazeno.

Frameworky pro MFE

Bit

Jeden z nejpopulárnější frameworků pro MFE. Umožňuje vytvářet a spravovat SubApps prostřednictvím nezávislých komponent. Jejich homepage je příkladem fungování samotného frameworku. Používá integraci built-time.

Module Federation

Umožňuje vyvíjet vícero samostatných buildů bez závislosti na kódu jiných celků. Každý je vyvíjen a nasazován nezávisle. Používá integraci run-time. Od verze 5 nabízí webpack možnost používat plugin Module Federation.

Základem celé aplikace postavené na architektuře MFE je kontejner. Jedná se o řídicí prvek, který rozhoduje o tom, kdy a kde se má daná SubApp zobrazit.

Single SPA

Princip spočívá v tom, že každá SubApp může reagovat na eventy z URL routingu a musí podporovat akce pro bootstrap, mount a unmount. Rozdíl oproti tradičním SPA spočívá v tom, že tady musí být aplikace postaveny tak, aby mohly koexistovat s ostatními. Není nutné, aby každá SubApp měla vlastní HTML stránku. Alespoň jedna SubApp (kontejner) musí být hostovaná remote. Používá integraci run-time.

Další frameworky

• Piral
• Luigi
• Qiankun
• Open Components
• Mosaic 9

Závěr

Pokud se během vývoje projektu vyskytnou problémy, které by vás mohly motivovat k tomu vydat se cestou architektury MFE, určitě byste to měli zvážit. V praxi se osvědčila a implementovaly ji velké firmy, jako je Ikea nebo Spotify. Je třeba mít na paměti, že architektura MFE přináší výhody, ale má i svá úskalí. Je důležité, aby se architekt správně rozhodl, jaká forma integrace bude v projektu implementovaná. Je třeba dbát na dodržování principů definovaných pro tuto architekturu a snažit se znalostmi pokrýt celý koncept, aby byl projekt dotažený do úspěšného konce. Jako odrazový můstek může pro začátek posloužit web micro-frontends.org