Micro-frontend-ներ

01Գաղափարը՝ բաժանել ըստ թիմի և բիզնես դոմենի

Պատկերացրեք e-commerce կայք, որը կառուցում են վեց թիմ՝ որոնում, ապրանքների էջեր, checkout, account, բովանդակություն և մարքեթինգ։ Մեկ ֆրոնտենդ կոդային բազայում յուրաքանչյուր փոփոխություն անցնում է մեկ build-ով և մեկ deploy-ով, և checkout-ի բագը կարող է արգելափակել որոնման թողարկումը։ Micro-frontend-ների դեպքում յուրաքանչյուր թիմ տիրապետում է ուղղահայաց շերտի՝ իր ռեպոզիտորիան կամ փաթեթը, իր pipeline-ը և իր deploy-ը։ Shell-ը (կոչվում է նաև host կամ container app) տրամադրում է էջի շրջանակը, routing-ը և ընդհանուր ծառայությունները, և յուրաքանչյուր ոլորտի համար բեռնում ճիշտ micro-frontend-ը։ Պատկերացրեք առևտրի կենտրոն. մեկ շենք, ընդհանուր միջանցքներ և անվտանգություն, բայց յուրաքանչյուր խանութ գործում է ինքնուրույն։ Հիմնական սկզբունքն է բաժանել ըստ բիզնես կարողության, ոչ թե տեխնիկական շերտի, ինչպես «header թիմ» և «կոճակների թիմ»։

• Shell / host. կազմում է էջը և տիրապետում routing-ին ու գլոբալ հարցերին։
• Remote / micro-frontend. UI-ի ինքնուրույն deploy արվող մաս։
• Contract. shell-ի և remote-ի միջև համաձայնեցված ինտերֆեյսը (props, իրադարձություններ, route-եր)։

02Micro-frontend-ների կոմպոզիցիայի եղանակներ

Կոմպոզիցիան կարող է տեղի ունենալ տարբեր ժամանակներում և տեղերում։ Build-time ինտեգրացիան յուրաքանչյուր մասը հրապարակում է որպես npm փաթեթ, որը shell-ը import է անում. պարզ և արագ, բայց կորցնում եք ինքնուրույն deploy-ը, որովհետև shell-ը պետք է վերակառուցվի։ Server-side կոմպոզիցիան HTML ֆրագմենտները կարում է սերվերում կամ edge-ում (Edge Side Includes, կոմպոզիցիայի ծառայություն կամ ֆրեյմվորքի հնարավորություններ, ինչպես Next.js Multi-Zones-ը, որտեղ տարբեր հավելվածներ տիրապետում են տարբեր URL ուղիների մեկ դոմենի հետևում)։ Run-time ինտեգրացիան յուրաքանչյուր թիմից JavaScript է բեռնում բրաուզերում՝ Module Federation, import map-եր native ES մոդուլներով կամ Web Components։ Iframe-երը տալիս են ամենաուժեղ մեկուսացումը, բայց վատ ինտեգրացիա layout-ի, routing-ի և accessibility-ի համար։ Ամենապարզ արդյունավետ մոտեցումը հաճախ route-ի մակարդակով բաժանումն է. յուրաքանչյուր թիմ տիրապետում է ամբողջական էջերի, և կիսվում է միայն shell-ի նավիգացիան։

03Module Federation-ի բացատրությունը

Module Federation-ը, որը ներդրվել է webpack 5-ում և այժմ հասանելի է որպես ինքնուրույն runtime (Module Federation 2.0)՝ webpack-ի, Rspack-ի, Rsbuild-ի և Vite-ի plugin-ներով, թույլ է տալիս մի build-ին run time-ում մոդուլներ բեռնել մեկ այլ build-ից։ Remote-ը մոդուլներ (օրինակ՝ ./ProductPage) է տրամադրում փոքր entry ֆայլի միջոցով, որը հաճախ կոչվում է remoteEntry.js կամ նկարագրվում mf-manifest.json-ով։ Host-ը հայտարարում է remote-ները և import է անում դրանց մոդուլները, կարծես դրանք լոկալ լինեին. կոդը բերվում է միայն անհրաժեշտության դեպքում։ Ընդհանուր կախվածությունները, ինչպես React-ը, հայտարարվում են որպես singleton-ներ, որպեսզի էջը բեռնի մեկ օրինակ, իսկ տարբերակների միջակայքերը համաձայնեցվում են run time-ում։ 2.0 տարբերակն ավելացնում է manifest պրոտոկոլ, type hint-եր remote-ների համար, runtime plugin համակարգ և devtools։

1// rsbuild.config.ts (remote: product team)
2import { defineConfig } from "@rsbuild/core";
3import { pluginReact } from "@rsbuild/plugin-react";
4import { pluginModuleFederation } from "@module-federation/rsbuild-plugin";
5 
6export default defineConfig({
7  plugins: [
8    pluginReact(),
9    pluginModuleFederation({
10      name: "product",
11      exposes: { "./ProductPage": "./src/ProductPage.tsx" },
12      shared: {
13        react: { singleton: true, requiredVersion: "^19.0.0" },
14        "react-dom": { singleton: true, requiredVersion: "^19.0.0" },
15      },
16    }),
17  ],
18  server: { port: 3001 },
19});

04Remote-ի օգտագործումը shell-ում

Host-ը հայտարարում է, թե որտեղ է ապրում յուրաքանչյուր remote, և ծույլ կերպով բեռնում դրա մոդուլները։ Յուրաքանչյուր remote փաթաթեք error boundary-ով և loading fallback-ով. remote-ը ցանցային կախվածություն է, որը կարող է ձախողվել կամ դանդաղ լինել, և մեկ կոտրված թիմը չպետք է կոտրի ամբողջ էջը։ Production-ում remote-ների URL-ները պետք է գան կոնֆիգուրացիայից կամ manifest ծառայությունից, ոչ թե hard-code արված լինեն, որպեսզի թիմերը կարողանան deploy և rollback անել՝ առանց shell-ը վերակառուցելու։

1// host: rsbuild.config.ts (excerpt)
2pluginModuleFederation({
3  name: "shell",
4  remotes: { product: "product@https://cdn.example.com/product/mf-manifest.json" },
5  shared: { react: { singleton: true }, "react-dom": { singleton: true } },
6});
7 
8// host: src/routes/ProductRoute.tsx
9import { lazy, Suspense } from "react";
10import { ErrorBoundary } from "react-error-boundary";
11 
12const ProductPage = lazy(() => import("product/ProductPage"));
13 
14export function ProductRoute() {
15  return (
16    <ErrorBoundary fallback={<p>Product details are unavailable right now.</p>}>
17      <Suspense fallback={<p>Loading…</p>}>
18        <ProductPage />
19      </Suspense>
20    </ErrorBoundary>
21  );
22}

05Հաղորդակցություն և ընդհանուր state

Micro-frontend-ները պետք է թույլ կապված լինեն, ուստի հաղորդակցվում են փոքր, բացահայտ պայմանագրերով, ոչ թե ընդհանուր գլոբալ store-ով։ Տարածված տարբերակներ. URL-ը և routing-ը որպես հիմնական state (ապրանքի ID-ն ապրում է URL-ում), props, որոնք shell-ը փոխանցում է remote-ը mount անելիս, բրաուզերի custom event-ներ ծանուցումների համար, ինչպես «զամբյուղը թարմացվել է», և բեքենդ API-ները որպես ճշմարտության աղբյուր, որը յուրաքանչյուր մաս կարդում է ինքնուրույն։ Խուսափեք բոլոր թիմերի կողմից կիսվող մեկ գլոբալ Redux store-ից. այն վերստեղծում է հենց այն կապվածությունը, որից խուսափելու համար բաժանել եք։ Authentication-ին սովորաբար տիրապետում է shell-ը, որը token getter կամ user context է տրամադրում փոքրիկ ընդհանուր ինտերֆեյսի միջոցով։

1// Contract: a typed custom event
2type CartUpdated = { count: number };
3 
4// Checkout micro-frontend
5window.dispatchEvent(new CustomEvent<CartUpdated>("cart:updated", { detail: { count: 3 } }));
6 
7// Shell header
8window.addEventListener("cart:updated", (e) => {
9  const { count } = (e as CustomEvent<CartUpdated>).detail;
10  renderBadge(count);
11});

06Դիզայն համակարգեր և հետևողականություն

Օգտատիրոջ համար տեսանելի ամենամեծ ռիսկը անհետևողական պրոդուկտն է. տարբեր կոճակներ, տարածություններ և վարքագծեր յուրաքանչյուր թիմից։ Ընդհանուր դիզայն համակարգը լուծում է սա. design token-ներ (գույներ, տարածություններ, տիպոգրաֆիա՝ որպես CSS փոփոխականներ), կոմպոնենտների գրադարան՝ հրապարակված որպես տարբերակավորված փաթեթ, և փաստաթղթավորում Storybook-ում։ Թիմերն այն օգտագործում են որպես ցանկացած կախվածություն։ Ոճերի մեկուսացումը նույնպես կարևոր է. օգտագործեք CSS Modules, նախածանց յուրաքանչյուր micro-frontend-ի համար կամ Shadow DOM Web Components-ի համար, որպեսզի մի թիմի գլոբալ CSS-ը չկոտրի մյուսի էջը։ Դիզայն համակարգի կոտրող փոփոխությունները պահեք հազվադեպ և հայտարարված, որովհետև յուրաքանչյուր թիմ պետք է թարմացնի. token-ները որպես CSS փոփոխականներ թույլ են տալիս թեման փոխել run time-ում՝ առանց յուրաքանչյուր remote-ը նորից deploy անելու։

07Monorepo, թե՞ polyrepo, և բուն որոշումը

Micro-frontend-ները ինքնուրույն deploy-ի մասին են, ոչ պարտադիր առանձին ռեպոզիտորիաների։ Շատ թիմեր օգտագործում են monorepo (Nx, Turborepo, pnpm workspaces)՝ մեկ թղթապանակ յուրաքանչյուր micro-frontend-ի համար, առանձին build և deploy pipeline-եր, որոնք գործարկվում են ազդված փոփոխություններով, և ընդհանուր գործիքներ։ Սա refactor-ները և կախվածությունների թարմացումները պահում է հեշտ՝ պահպանելով թիմերի սեփականությունը։ Polyrepo-ները առավելագույնի են հասցնում ինքնավարությունը, բայց դժվարացնում են ընդհանուր թարմացումները և հետևողականությունը։ Որևէ մեկն ընտրելուց առաջ հարցրեք՝ արդյոք ընդհանրապես micro-frontend-ներ պետք են. մոտ երեք-չորսից պակաս ֆրոնտենդ թիմի դեպքում լավ կառուցված մոդուլային մոնոլիտը՝ թղթապանակների հստակ սեփականությամբ, lint-ով պարտադրված սահմաններով և արագ CI-ով, սովորաբար տալիս է օգուտները՝ առանց run-time բարդության։

08Ընդհանուր կախվածություններ և տարբերակների համաձայնեցում

Module Federation-ի share scope-ը run-time ռեեստր է, որտեղ յուրաքանչյուր բեռնված build գրանցում է իր բերած ընդհանուր փաթեթները՝ տարբերակներով։ Երբ մոդուլին React է պետք, runtime-ը ընտրում է requiredVersion-ին բավարարող տարբերակ՝ նախընտրելով ամենաբարձր հասանելին, իսկ singleton: true-ն պարտադրում է ճիշտ մեկ instance, ինչը պահանջում են React-ը, React DOM-ը, router-ները և context-ի վրա հիմնված գրադարանները, որովհետև երկու օրինակը կոտրում է hook-երը և context-ը։ Եթե համատեղելի տարբերակ չկա, singleton-ը զգուշացում է լոգավորում և միևնույն է օգտագործում բեռնվածը, ինչը կարող է նուրբ բագեր առաջացնել. strictVersion-ը դա վերածում է սխալի։ eager: true-ն ընդհանուր մոդուլը փաթեթավորում է սկզբնական chunk-ի մեջ, ինչը խուսափում է async սահմանից, բայց մեծացնում է չափը։ Սովորական pattern-ը async bootstrap-ն է. entry ֆայլը կատարում է import('./bootstrap'), որպեսզի ընդհանուր մոդուլները համաձայնեցվեն մինչև հավելվածի գործարկումը։

1// src/index.ts  (entry)
2import("./bootstrap");
3 
4// src/bootstrap.tsx
5import { createRoot } from "react-dom/client";
6import { App } from "./App";
7createRoot(document.getElementById("root")!).render(<App />);
8 
9// shared config with strict checks for critical libs
10// shared: {
11//   react: { singleton: true, requiredVersion: "^19.0.0", strictVersion: true },
12//   "@acme/design-system": { singleton: true, requiredVersion: "^4.2.0" },
13// }

09Deploy, discovery և rollback-ներ

Ինքնուրույն deploy-ի համար shell-ին պետք է եղանակ՝ յուրաքանչյուր remote-ի ընթացիկ տարբերակը գտնելու։ URL-ները shell-ի build-ում hard-code անելը կապում է deploy-երը։ Ավելի լավ է. յուրաքանչյուր remote հրապարակում է անփոփոխ, տարբերակավորված ռեսուրսներ (product/1.14.2/mf-manifest.json) CDN-ում, իսկ փոքր discovery փաստաթուղթը կամ ծառայությունը remote-ների անունները համապատասխանեցնում է ակտիվ տարբերակին ըստ միջավայրի։ Shell-ը կարդում է այն գործարկման ժամանակ, կամ Module Federation-ի runtime plugin-ները դինամիկ լուծում են remote-ները։ Rollback-ը նշանակում է քարտեզը ուղղել նախորդ տարբերակին՝ առանց որևէ բան վերակառուցելու։ Սա հնարավոր է դարձնում նաև canary թողարկումներ և թեստավորման համար ըստ օգտատիրոջ override-ներ։ Discovery փաստաթուղթը քեշավորեք կարճ, իսկ ռեսուրսներին տվեք երկար քեշի ժամկետ, որովհետև դրանց ուղիները տարբերակավորված են։

1// remotes.json served by a config endpoint (short cache)
2{
3  "product":  "https://cdn.example.com/product/1.14.2/mf-manifest.json",
4  "checkout": "https://cdn.example.com/checkout/3.2.0/mf-manifest.json"
5}
6 
7// shell bootstrap with the MF runtime
8import { init } from "@module-federation/enhanced/runtime";
9const remotes = await (await fetch("/config/remotes.json")).json();
10init({
11  name: "shell",
12  remotes: Object.entries(remotes).map(([name, entry]) => ({ name, entry: entry as string })),
13});

10Մեկուսացում. CSS, գլոբալներ և ձախողումներ

Run-time կոմպոզիցիան մի քանի թիմերի կոդը դնում է նույն փաստաթղթում, ուստի մեկուսացումը պետք է նախագծել։ CSS. մի remote-ի գլոբալ selector-ները կարող են վերաոճավորել մյուսը. օգտագործեք CSS Modules կամ ֆրեյմվորքի scoped ոճերը, ցանկացած գլոբալ class-ի նախածանց տվեք և reset-ները պահեք միայն shell-ում։ Web Components-ը Shadow DOM-ով տալիս են ոճերի կոշտ սահմաններ՝ թեմավորման դժվարացման գնով (օգտագործեք CSS custom properties, որոնք թափանցում են shadow սահմանը)։ JavaScript գլոբալներ. երբեք remote-ում patch մի արեք window-ը կամ prototype-ները, և ցանկացած storage key-ի namespace տվեք։ Ձախողումներ. error boundary յուրաքանչյուր remote-ի համար, timeout-ներ remote-ների բեռնման վրա և fallback UI-ը էջը պահում են օգտագործելի։ Սխալներն ու արտադրողականության մետրիկաները tag արեք remote-ի անունով և տարբերակով, որպեսզի on-call ինժեներները իմանան, թե որ թիմին զանգահարել։

11Server-side կոմպոզիցիա և SSR

Client-side federation-ն աշխատում է login-ի հետևում գտնվող հավելվածների համար, բայց հանրային էջերին պետք է արագ first paint և SEO։ Տարբերակներ. route-ի մակարդակի սերվերային հավելվածներ մեկ դոմենի հետևում (Next.js Multi-Zones կամ reverse proxy, որը /checkout-ն ուղղորդում է մի հավելվածի, իսկ /blog-ը՝ մյուսին), ինչը պարզ է և հուսալի, բայց նշանակում է zone-երի միջև էջի ամբողջական բեռնումներ. HTML ֆրագմենտների edge կամ սերվերային կոմպոզիցիա, որտեղ layout ծառայությունը զուգահեռ բերում է ֆրագմենտները յուրաքանչյուր թիմից և stream անում դրանք, կամ federated SSR, որտեղ Module Federation-ը remote մոդուլները բեռնում է նաև Node.js սերվերում, ինչը հզոր է, բայց բարդ շահագործման համար՝ սերվերային քեշավորման և հիշողության հարցերով։ Հանրային կայքերի մեծ մասի համար route-ի մակարդակի zone-երը գումարած ընդհանուր դիզայն համակարգն ու header փաթեթը պրագմատիկ պատասխանն են։

1# nginx: route-level composition under one domain
2location /checkout/ { proxy_pass http://127.0.0.1:3002; }
3location /account/  { proxy_pass http://127.0.0.1:3003; }
4location /          { proxy_pass http://127.0.0.1:3001; }  # main shop