- Přírůstková migrace umožňuje týmům uškrtit starší monolity nahrazováním vysoce hodnotných fragmentů uživatelského rozhraní bez riskantního úplného přepisování.
- Organizační autonomie se dosahuje sladěním mikrofrontendů s obchodními subdoménami, což umožňuje nezávislé cykly nasazení.
- Technické složení lze zpracovat pomocí fragmentů na straně serveru, federace modulů nebo integrace běhového JavaScriptu v závislosti na potřebách výkonu.
Buďme realističtí: většina velkých podnikových webových aplikací jsou v podstatě obrovské koule bláta. Když máte masivní monolitický frontend, škálování vašeho vývoje se stává noční můrou, protože si všichni šlapou na palec a jediná chyba může zhatit celou show. Myšlenka totálního přepracování je lákavá, ale v reálném světě je to obvykle sebevražedná mise, která trvá roky, než uživatelé uvidí jedinou výhodu.
A právě zde se projevuje kouzlo postupného zavádění . Místo přepínání přepínače začnete monolit vyřezávat kousek po kousku. Tím, že budete s frontendem zacházet jako se souborem nezávisle dodávaných aplikací, můžete modernizovat svůj technologický stack a umožnit svým týmům postupovat rychleji bez stresu z vysoce rizikového nasazení s velkým třeskem. Jde o nalezení té ideální rovnováhy mezi stabilitou a agilitou.
Strategie propichování fragmentů
Jedním z nejlepších způsobů, jak zvládnout přechod na starší verzi, je technika zvaná „ piercing fragmentů “. Představte si, že máte pomalu se načítající aplikaci v Reactu; místo čekání na spuštění celého shellu můžete vykreslit fragmenty na straně serveru (pomocí nástrojů, jako je Cloudflare Workers), které jsou interaktivní téměř okamžitě. Tyto fragmenty jsou nejprve umístěny na nejvyšší úrovni HTML a poté, co je starší shell konečně dožene, jsou „piercingovány“ nebo přesunuty na správné místo v DOMu.
Tento přístup je záchranou pro vylepšení Core Web Vitals, protože zkracuje dobu interaktivního procesu. Například byste mohli přihlašovací formulář proměnit v samostatný fragment. Uživatelé mohou začít zadávat své přihlašovací údaje ještě předtím, než se hlavní aplikace v prohlížeči vůbec objeví. Pro zajištění plynulosti lze použít sběrnici zpráv (Message Bus) jako způsob, jak tyto fragmenty komunikovat se starší aplikací nezávisle na frameworku, aniž by vytvářely těsné propojení.
Architektonické přístupy k integraci
V závislosti na vašich cílech existuje několik způsobů, jak tyto části spojit dohromady. Kompozice šablon na straně serveru je staromódní, ale spolehlivá metoda, která využívá například Nginx k vkládání fragmentů HTML. Pokud chcete větší flexibilitu, integrace za běhu pomocí JavaScriptu umožňuje kontejnerové aplikaci stáhnout balíček a volat globální funkci renderování. Pro ty, kteří milují nativní funkce prohlížeče, webové komponenty nabízejí standardizovaný způsob definování vlastních prvků, jejichž instance může shell jednoduše vytvořit.
Moderní platformy se stále více přiklánějí k Module Federation . To umožňuje aplikaci dynamicky načítat moduly z jiného sestavení za běhu. Použitím modelu spotřebitele a poskytovatele můžete sdílet singletony jako React nebo Vue, takže uživatel nemusí pětkrát stahovat stejný framework. Zlatým standardem pro vyhnutí se „peklu závislostí“ je však často monorepozitář , který zajišťuje, že všechny mikrofrontendy jsou před spuštěním testovány na stejných verzích knihoven.
Vyhněte se běžným nástrahám
Je snadné to přehnat a vytvořit anarchii mikrofrontendů . Častou chybou je myslet si, že mikrofrontendy jsou jen „velké komponenty“. Tlačítko je komponenta; proces platby je mikrofrontend. Pokud začnete každý malý prvek uživatelského rozhraní vytvářet jako samostatný nasaditelný prvek, jen tím zbytečně zvyšujete provozní složitost . Vždy byste měli sladit své hranice s obchodními subdoménami , nikoli s technickými vrstvami.
Další pastí je pokušení používat více frameworků . Jen proto, že můžete na jedné stránce provozovat Angular, React a Svelte, neznamená to, že byste to měli dělat. Snižuje to výkon a fragmentuje vaši základnu talentů. Jediný případ, kdy to dává smysl, je během migrační strategie nebo po akvizici. Abyste zabránili přílišnému propletení vašich aplikací, vyhněte se sdílenému globálnímu stavu. Místo toho se spoléhejte na jednosměrný tok dat a komunikaci řízenou událostmi, aby týmy zůstaly skutečně autonomní.
Kompromis: Autonomie vs. režijní náklady
V architektuře neexistuje nic jako oběd zdarma. Volbou mikrofrontendů vyměňujete atomické verze za nezávislé. To znamená, že se můžete potýkat s verzí skew , kdy různé části stránky používají různé verze sdílené knihovny. Pokud nebudete opatrní se sdílenými závislostmi, dojde také ke zvýšení celkové velikosti datového zatížení .
Z organizačního hlediska budete potřebovat více CI/CD kanálů a lepší sledovatelnost. Pro velkou společnost je to však obrovská odměna: snížená kognitivní zátěž pro vývojáře a možnost vytvořit nové týmy, které budou zodpovědné za funkci od nápadu až po produkci. Pokud zjistíte, že více mikrofrontendů zahlcuje stejný koncový bod API, je to signál k přehodnocení vašich hranic nebo k zavedení Backendu pro Frontend (BFF), který agreguje tato volání a zabraňuje nekontrolovanému rozpínání API.
