Module Federation: A Végleges Útmutató a Futásidejű Modulmegosztáshoz a Mikro-Frontend Architektúrában

A webfejlesztés folyamatosan változó világában jelentős architekturális elmozdulásnak lehettünk tanúi. A monolitikus architektúráktól a backend mikroszolgáltatások felé vettük az irányt, a skálázhatóságot és a csapatok autonómiáját keresve. Most ugyanez a forradalom alakítja át a frontendet. Elérkezett a mikro-frontendek korszaka, amelynek középpontjában egy erőteljes technológia áll, ami mindezt a gyakorlatban is lehetővé teszi: a Module Federation.

A mikro-frontendek alapvető kihívása mindig is egyszerűen megfogalmazható, de nehezen megoldható volt: hogyan építhetünk egyetlen, koherens felhasználói élményt több, egymástól függetlenül telepített alkalmazásból anélkül, hogy egy lassú, túlzsúfolt és kezelhetetlen rendszert hoznánk létre? Hogyan oszthatjuk meg a közös kódot, például komponenskönyvtárakat vagy olyan keretrendszereket, mint a React, anélkül, hogy verziókezelési rémálmokat okoznánk vagy összehangolt kiadásokat kényszerítenénk ki?

Ezt a problémát oldja meg elegánsan a Module Federation. A Webpack 5-ben bevezetett technológia nem csupán egy újabb funkció; ez egy paradigmaváltás abban, ahogyan a webalkalmazások építéséről és telepítéséről gondolkodunk. Ez az átfogó útmutató feltárja a Module Federation miértjét, mitjét és hogyanját, különös tekintettel annak leginkább átalakító képességére: a futásidejű modulmegosztásra.

Gyors Ismétlés: Mik azok a Mikro-Frontendek?

Mielőtt belemerülnénk a Module Federation mechanikájába, tisztázzuk, mit is értünk mikro-frontendek alatt. Képzeljünk el egy nagy e-kereskedelmi weboldalt. Egy monolitikus világban a teljes frontend – a termékkeresés, a termékadatlapok, a kosár és a fizetési folyamat – egyetlen, nagy alkalmazást alkot. Egy változtatás a fizetési gombón az egész alkalmazás tesztelését és újratelepítését teheti szükségessé.

A mikro-frontend architektúra ezt a monolitot üzleti területek mentén bontja le. Így lehet például:

• Egy Kereső Csapat, amely a keresősávért és a találati oldalért felel.
• Egy Termék Csapat, amely a termékadatlapokért és ajánlásokért felel.
• Egy Fizetési Csapat, amely a bevásárlókosárért és a fizetési folyamatért felel.

Minden csapat önállóan építheti, tesztelheti és telepítheti az alkalmazás rá eső részét. Ez számos kulcsfontosságú előnnyel jár:

• Autonóm Csapatok: A csapatok a saját ütemtervük szerint dolgozhatnak és adhatnak ki új verziókat, ami felgyorsítja a fejlesztést.
• Független Telepítések: Egy hiba az ajánlómotorban nem blokkolja a fizetési folyamat egy kritikus frissítését.
• Technológiai Rugalmasság: A kereső csapat használhat Vue.js-t, míg a termék csapat Reactet, lehetővé téve, hogy a csapatok a saját területüknek legmegfelelőbb eszközt válasszák (bár ez gondos menedzsmentet igényel).

Ez a megközelítés azonban saját kihívásokat is felvet, elsősorban a megosztás és a következetesség terén, ami elvezet minket a régi módszerekhez.

A Kódmegosztás Régi Módszerei (És Miért Elégtelenek)

A múltban a csapatok többféle módszerrel próbálták megosztani a kódot a különböző frontend alkalmazások között, de mindegyiknek jelentős hátrányai voltak egy mikro-frontend környezetben.

NPM Csomagok

A leggyakoribb megközelítés a megosztott komponensek vagy segédfüggvények verziózott NPM csomagként való közzététele. Egy megosztott komponenskönyvtár klasszikus példa erre.

• A Probléma: Ez egy build-idejű (build-time) függőség. Ha az A csapat frissíti a megosztott `Button` komponenst a `my-ui-library` csomagban 1.1-ről 1.2-re, a B és C csapat addig nem kapja meg a frissítést, amíg manuálisan nem frissítik a `package.json` fájljukat, nem futtatják az `npm install`-t, és nem telepítik újra a teljes mikro-frontendjüket. Ez szoros csatolást hoz létre, és meghiúsítja a független telepítések célját. Emellett ahhoz is vezet, hogy ugyanannak a komponensnek több verziója is betöltődik a böngészőben, feleslegesen növelve a végső csomagméretet.

Monorepók Megosztott Munkaterületekkel

A monorepók (olyan eszközökkel, mint a Lerna vagy a Yarn/NPM workspaces) az összes mikro-frontendet egyetlen repositoryban tárolják. Ez leegyszerűsíti a megosztott csomagok kezelését.

• A Probléma: Bár a monorepók segítik a fejlesztői élményt, nem oldják meg az alapvető futásidejű problémát. Továbbra is build-idejű függőségekre támaszkodnak. Egy megosztott könyvtárban végzett változtatás továbbra is megköveteli az összes azt használó alkalmazás újraépítését és újratelepítését a változás érvényesítéséhez.

Külső Szkriptek `