Micro-frontends jsou odpověď na organizační problém, ne na technický
Definice zní suše: nezávisle nasaditelné frontendové aplikace složené do jednoho celku. Z ní se dá snadno odvodit, že jde o způsob, jak rozdělit velký frontend na menší kusy. To je nepřesné čtení.
Rozdělit kód na moduly umíš i v monolitu. Co v monolitu neumíš, je nasadit jednu část, aniž bys čekal na ostatní. Právě tuhle jedinou vlastnost si micro-frontends kupují, a všechno ostatní je buď důsledek, nebo cena.
Build-time integrace ruší to, kvůli čemu to děláš
Přístupů ke složení je několik a liší se právě v tom, kolik nezávislosti zachovají.
Skládání šablon na serveru je tradiční a levné, ale každý tým je vázaný na společné nasazení serveru. Integrace v build time přes npm balíčky vypadá čistě a je to past: aby se změna jednoho balíčku dostala k uživateli, musí se přebuildit a nasadit kontejner. Tím se všechny týmy vrátí do společného release cyklu a jediný zisk, kvůli kterému se to dělalo, je pryč.
Nezávislost drží až integrace za běhu. Buď přes iframe, který dává nejtvrdší izolaci a nejhorší ergonomii pro cokoli, co jde napříč aplikacemi, nebo přes JavaScript, kde micro-frontend vystaví globální funkci a kontejner ji zavolá, nebo přes web components jako standardizovanou variantu téhož.
Rozhodovací pravidlo je jednoduché. Pokud se pro nasazení jedné části musí přebuildit celek, nemáš micro-frontends, máš monorepo s horší ergonomií.
Cenu platí někdo, kdo u rozhodnutí nebyl
Nezávisle přeložené balíky nemají jak sdílet společné závislosti. Každý micro-frontend si nese svou verzi knihoven a uživatel je při průchodu aplikací stahuje znovu.
Tahle věc nemá čisté řešení. Deduplikace závislostí vyžaduje, aby někdo centrálně rozhodl o verzích, což je přesně ta vazba mezi týmy, kterou architektura odstraňuje. Sdílení přes externals a import mapy to zmírní a zároveň vrátí kus koordinace zpátky. Napětí mezi autonomií a velikostí staženého kódu zůstává nevyřešené.
Druhá cena je prostředí. Micro-frontend se vyvíjí samostatně, ale běží v kontejneru, který při vývoji nevidíš. Globální styly, kolize selektorů a rozdíly v runtime se proto projeví až po nasazení. Odpovědí je agresivní integrační testování a vývojové prostředí co nejblíž produkci, tedy další režie.
Třetí cena je provozní. Víc repozitářů, víc pipeline, víc infrastruktury a decentralizované rozhodování, které potřebuje aspoň minimální společný standard kvality, jinak se z autonomie stane nesourodost.
Co za to dostaneš, když to sedí
Výnosy jsou reálné, jen mají úzkou cílovou skupinu. Inkrementální modernizace: starou část přepíšeš kus po kuse a nepotřebuješ velký rewrite. Menší kódové báze, ve kterých se náhodná provázanost mezi nesouvisejícími částmi hůř vyrábí. Nezávislý deployment, který snižuje riziko každého vydání. A týmy vlastnící funkcionalitu svisle, od záměru po produkci.
Všechny čtyři výnosy mají společného jmenovatele: předpokládají víc týmů. Ani jeden z nich nedává nic týmu jedinému, protože ten žádnou koordinační bariéru nepřekonává.
Co si z toho odnést
Než se pro micro-frontends rozhodneš, odpověz si na jednu otázku o organizaci, ne o kódu: brzdí nás dnes při nasazení čekání na jiný tým. Pokud ne, platíš stahováním duplicitních závislostí, provozem několika pipeline a třídou chyb, které se projeví až v integraci, a nekupuješ za to nic.
Pokud ano, drž se dvou pravidel. Integruj za běhu, protože jakákoli integrace v build time vrátí týmy do společného release cyklu. A napiš dopředu, co je povinné napříč všemi částmi, tedy verze frameworku, design tokeny, chování při chybě. Autonomie bez minimálního společného základu se z pohledu uživatele projeví jako čtyři různé aplikace pod jednou doménou.
A poslední věc, kterou článek říká mezi řádky: hranice mezi micro-frontendy má kopírovat hranice domén a týmů. Když je vedeš podle technických vrstev, dostaneš všechny náklady a žádnou autonomii.