Frontend Micro-Frontend: Module Federation arhitektuuri valdamine

Tänapäeva kiiresti areneval veebiarenduse maastikul võib suuremahuliste frontend-rakenduste loomine ja hooldamine muutuda üha keerulisemaks. Traditsioonilised monoliitsed arhitektuurid põhjustavad sageli väljakutseid, nagu koodi paisumine, aeglased ehitusajad ja raskused sõltumatute juurutustega. Micro-frontendid pakuvad lahendust, jaotades frontendi väiksemateks, paremini hallatavateks osadeks. See artikkel süveneb Module Federation'i, mis on võimas tehnika micro-frontendide rakendamiseks, uurides selle eeliseid, arhitektuuri ja praktilisi rakendusstrateegiaid.

Mis on Micro-Frontendid?

Micro-frontendid on arhitektuuristiil, kus frontend-rakendus jaotatakse väiksemateks, sõltumatuteks ja juurutatavateks üksusteks. Iga micro-frontend on tavaliselt eraldi meeskonna omanduses, mis võimaldab suuremat autonoomiat ja kiiremaid arendustsükleid. See lähenemine peegeldab mikroteenuste arhitektuuri, mida tavaliselt kasutatakse backendis.

Micro-frontendide peamised omadused on järgmised:

• Sõltumatu juurutatavus: Iga micro-frontendi saab juurutada iseseisvalt, mõjutamata teisi rakenduse osi.
• Meeskonna autonoomia: Erinevad meeskonnad saavad omada ja arendada erinevaid micro-frontende, kasutades oma eelistatud tehnoloogiaid ja töövooge.
• Tehnoloogiline mitmekesisus: Micro-frontende saab ehitada erinevate raamistike ja teekidega, võimaldades meeskondadel valida töö jaoks parimad vahendid.
• Isolatsioon: Micro-frontendid peaksid olema üksteisest isoleeritud, et vältida kaskaadtõrkeid ja tagada stabiilsus.

Miks kasutada Micro-Frontende?

Micro-frontend arhitektuuri kasutuselevõtt pakub mitmeid olulisi eeliseid, eriti suurte ja keerukate rakenduste puhul:

• Parem skaleeritavus: Frontendi jaotamine väiksemateks üksusteks muudab rakenduse vajaduspõhise skaleerimise lihtsamaks.
• Kiiremad arendustsüklid: Sõltumatud meeskonnad saavad töötada paralleelselt, mis viib kiiremate arendus- ja väljalasketsükliteni.
• Suurem meeskonna autonoomia: Meeskondadel on rohkem kontrolli oma koodi üle ja nad saavad teha otsuseid iseseisvalt.
• Lihtsam hooldus: Väiksemaid koodibaase on lihtsam hooldada ja siluda.
• Tehnoloogiast sõltumatu: Meeskonnad saavad valida oma spetsiifilistele vajadustele parimad tehnoloogiad, võimaldades innovatsiooni ja katsetamist.
• Vähendatud risk: Juurutused on väiksemad ja sagedasemad, vähendades suuremahuliste tõrgete riski.

Sissejuhatus Module Federation'i

Module Federation on Webpack 5-s tutvustatud funktsioon, mis võimaldab JavaScripti rakendustel dünaamiliselt laadida koodi teistest rakendustest käitusajal. See võimaldab luua tõeliselt sõltumatuid ja komponeeritavaid micro-frontende. Selle asemel, et ehitada kõik ühte kimpu, võimaldab Module Federation erinevatel rakendustel jagada ja tarbida üksteise mooduleid, justkui oleksid need kohalikud sõltuvused.

Erinevalt traditsioonilistest micro-frontendide lähenemistest, mis tuginevad iframe'idele või veebikomponentidele, pakub Module Federation kasutajale sujuvamat ja integreeritumat kogemust. See väldib nende teiste tehnikatega seotud jõudluse lisakulu ja keerukust.

Kuidas Module Federation töötab

Module Federation toimib moodulite "paljastamise" (exposing) ja "tarbimise" (consuming) kontseptsioonil. Üks rakendus ("host" või "konteiner") saab mooduleid paljastada, samas kui teised rakendused ("remotes") saavad neid paljastatud mooduleid tarbida. Siin on protsessi jaotus:

1. Mooduli paljastamine: Micro-frontend, mis on Webpackis konfigureeritud kui "remote" rakendus, paljastab teatud moodulid (komponendid, funktsioonid, utiliidid) konfiguratsioonifaili kaudu. See konfiguratsioon määrab jagatavad moodulid ja nende vastavad sisenemispunktid.
2. Mooduli tarbimine: Teine micro-frontend, mis on konfigureeritud kui "host" või "konteiner" rakendus, deklareerib "remote" rakenduse sõltuvusena. See määrab URL-i, kust on leitav "remote" rakenduse mooduliföderatsiooni manifest (väike JSON-fail, mis kirjeldab paljastatud mooduleid).
3. Käitusaegne lahendamine: Kui "host" rakendus peab kasutama moodulit "remote" rakendusest, hangib see dünaamiliselt "remote" rakenduse mooduliföderatsiooni manifesti. Seejärel lahendab Webpack mooduli sõltuvuse ja laadib vajaliku koodi "remote" rakendusest käitusajal.
4. Koodi jagamine: Module Federation võimaldab ka koodi jagamist "host" ja "remote" rakenduste vahel. Kui mõlemad rakendused kasutavad sama versiooni jagatud sõltuvusest (nt React, lodash), jagatakse koodi, vältides dubleerimist ja vähendades kimpude suurust.

Module Federation'i seadistamine: praktiline näide

Illustreerime Module Federation'i lihtsa näitega, mis hõlmab kahte micro-frontendi: "Tootekataloog" ja "Ostukorv". Tootekataloog paljastab toodete loendi komponendi, mida Ostukorv tarbib seotud toodete kuvamiseks.

Projekti struktuur

  
  micro-frontend-example/
    product-catalog/
      src/
        components/
          ProductList.jsx
        index.js
        webpack.config.js
    shopping-cart/
      src/
        components/
          RelatedProducts.jsx
        index.js
        webpack.config.js
  

Tootekataloog (Remote)

webpack.config.js

  
  const { ModuleFederationPlugin } = require('webpack').container;
  const path = require('path');

  module.exports = {
    // ... other webpack configurations
    plugins: [
      new ModuleFederationPlugin({
        name: 'product_catalog',
        filename: 'remoteEntry.js',
        exposes: {
          './ProductList': './src/components/ProductList',
        },
        shared: {
          react: { singleton: true, eager: true, requiredVersion: '^17.0.0' },
          'react-dom': { singleton: true, eager: true, requiredVersion: '^17.0.0' },
        },
      }),
    ],
  };
  

Selgitus:

• name: "Remote" rakenduse unikaalne nimi.
• filename: Paljastatava sisenemispunkti faili nimi. See fail sisaldab mooduliföderatsiooni manifesti.
• exposes: Määratleb, milliseid mooduleid see rakendus paljastab. Sel juhul paljastame `ProductList` komponendi asukohast `src/components/ProductList.jsx` nime all `./ProductList`.
• shared: Määrab sõltuvused, mida tuleks jagada "host" ja "remote" rakenduste vahel. See on ülioluline koodi dubleerimise vältimiseks ja ühilduvuse tagamiseks. `singleton: true` tagab, et laaditakse ainult üks jagatud sõltuvuse eksemplar. `eager: true` laadib jagatud sõltuvuse esialgu, mis võib parandada jõudlust. `requiredVersion` määratleb jagatud sõltuvuse aktsepteeritava versioonivahemiku.

src/components/ProductList.jsx

  
  import React from 'react';

  const ProductList = ({ products }) => (
    

      {products.map((product) => (
        
{product.name} - ${product.price}
      ))}
    
  );

  export default ProductList;
  

Ostukorv (Host)

webpack.config.js

  
  const { ModuleFederationPlugin } = require('webpack').container;
  const path = require('path');

  module.exports = {
    // ... other webpack configurations
    plugins: [
      new ModuleFederationPlugin({
        name: 'shopping_cart',
        remotes: {
          product_catalog: 'product_catalog@http://localhost:3001/remoteEntry.js',
        },
        shared: {
          react: { singleton: true, eager: true, requiredVersion: '^17.0.0' },
          'react-dom': { singleton: true, eager: true, requiredVersion: '^17.0.0' },
        },
      }),
    ],
  };
  

Selgitus:

• name: "Host" rakenduse unikaalne nimi.
• remotes: Määratleb "remote" rakendused, millest see rakendus mooduleid tarbib. Sel juhul deklareerime "remote" nimega `product_catalog` ja määrame URL-i, kust selle `remoteEntry.js` faili leida võib. Formaat on `remoteNimi: 'remoteNimi@remoteEntryUrl'`.
• shared: Sarnaselt "remote" rakendusele määratleb ka "host" rakendus oma jagatud sõltuvused. See tagab, et "host" ja "remote" rakendused kasutavad jagatud teekide ühilduvaid versioone.

src/components/RelatedProducts.jsx

  
  import React, { useEffect, useState } from 'react';
  import ProductList from 'product_catalog/ProductList';

  const RelatedProducts = () => {
    const [products, setProducts] = useState([]);

    useEffect(() => {
      // Fetch related products data (e.g., from an API)
      const fetchProducts = async () => {
        // Replace with your actual API endpoint
        const response = await fetch('https://fakestoreapi.com/products?limit=3');
        const data = await response.json();
        setProducts(data);
      };

      fetchProducts();
    }, []);

    return (
      

        
Related Products
        {products.length > 0 ?  : 
Loading...
}
      
    );
  };

  export default RelatedProducts;
  

Selgitus:

• import ProductList from 'product_catalog/ProductList'; See rida impordib `ProductList` komponendi `product_catalog` "remote'ist". Süntaks `remoteNimi/mooduliNimi` annab Webpackile käsu hankida moodul määratud "remote" rakendusest.
• Seejärel kasutab komponent imporditud `ProductList` komponenti seotud toodete kuvamiseks.

Näite käivitamine

1. Käivitage nii Tootekataloogi kui ka Ostukorvi rakendused, kasutades nende vastavaid arendusservereid (nt `npm start`). Veenduge, et need töötaksid erinevatel portidel (nt Tootekataloog pordil 3001 ja Ostukorv pordil 3000).
2. Avage oma brauseris Ostukorvi rakendus.
3. Peaksite nägema jaotist "Seotud tooted", mida renderdab Tootekataloogi rakendusest pärinev `ProductList` komponent.

Module Federation'i edasijõudnud kontseptsioonid

Lisaks põhilisele seadistusele pakub Module Federation mitmeid edasijõudnud funktsioone, mis võivad teie micro-frontend arhitektuuri täiustada:

Koodi jagamine ja versioonihaldus

Nagu näites demonstreeritud, võimaldab Module Federation koodi jagamist "host" ja "remote" rakenduste vahel. See saavutatakse Webpacki `shared` konfiguratsioonivaliku kaudu. Jagatud sõltuvuste määramisega saate vältida koodi dubleerimist ja vähendada kimpude suurust. Jagatud sõltuvuste korrektne versioonihaldus on ühilduvuse tagamiseks ja konfliktide vältimiseks ülioluline. Semantiline versioonimine (SemVer) on laialt levinud tarkvara versioonimise standard, mis võimaldab teil määratleda ühilduvaid versioonivahemikke (nt `^17.0.0` lubab mis tahes versiooni, mis on suurem või võrdne 17.0.0-ga, kuid väiksem kui 18.0.0).

Dünaamilised "remote'id"

Eelmises näites oli "remote" URL `webpack.config.js` failis kõvakodeeritud. Paljudes reaalsetes stsenaariumides võib aga tekkida vajadus määrata "remote" URL dünaamiliselt käitusajal. Seda on võimalik saavutada, kasutades lubaduspõhist "remote" konfiguratsiooni:

  
  // webpack.config.js
  remotes: {
    product_catalog: new Promise(resolve => {
      // Fetch the remote URL from a configuration file or API
      fetch('/config.json')
        .then(response => response.json())
        .then(config => {
          const remoteUrl = config.productCatalogUrl;
          resolve(`product_catalog@${remoteUrl}/remoteEntry.js`);
        });
    }),
  },
  

See võimaldab teil konfigureerida "remote" URL-i vastavalt keskkonnale (nt arendus, testimine, tootmine) või muudele teguritele.

Asünkroonne moodulite laadimine

Module Federation toetab asünkroonset moodulite laadimist, mis võimaldab teil laadida mooduleid vastavalt vajadusele. See võib parandada teie rakenduse esialgset laadimisaega, lükates edasi mittekriitiliste moodulite laadimise.

  
  // RelatedProducts.jsx
  import React, { Suspense, lazy } from 'react';

  const ProductList = lazy(() => import('product_catalog/ProductList'));

  const RelatedProducts = () => {
    return (
      

        
Related Products
        Loading...
}>
          
        
      
    );
  };
  

Kasutades `React.lazy` ja `Suspense`, saate asünkroonselt laadida `ProductList` komponendi "remote" rakendusest. `Suspense` komponent pakub varu-UI-d (nt laadimisindikaatorit), kuni moodulit laaditakse.

Federeeritud stiilid ja varad

Module Federation'i saab kasutada ka stiilide ja varade (assets) jagamiseks micro-frontendide vahel. See aitab säilitada teie rakenduses ühtset välimust ja tunnetust.

Stiilide jagamiseks saate paljastada CSS-mooduleid või "styled components" "remote" rakendusest. Varade (nt pildid, fondid) jagamiseks saate konfigureerida Webpacki kopeerima varad jagatud asukohta ja seejärel viitama neile "host" rakendusest.

Module Federation'i parimad praktikad

Module Federation'i rakendamisel on oluline järgida parimaid praktikaid, et tagada edukas ja hooldatav arhitektuur:

• Määratlege selged piirid: Määratlege selgelt micro-frontendide vahelised piirid, et vältida tihedat sidumist ja tagada sõltumatu juurutatavus.
• Kehtestage suhtlusprotokollid: Määratlege selged suhtlusprotokollid micro-frontendide vahel. Kaaluge sündmussiinide (event buses), jagatud olekuhaldusteekide või kohandatud API-de kasutamist.
• Hallake jagatud sõltuvusi hoolikalt: Hallake hoolikalt jagatud sõltuvusi, et vältida versioonikonflikte ja tagada ühilduvus. Kasutage semantilist versioonimist ja kaaluge sõltuvuste haldamise tööriista, nagu npm või yarn, kasutamist.
• Rakendage robustne veakäsitlus: Rakendage robustne veakäsitlus, et vältida kaskaadtõrkeid ja tagada oma rakenduse stabiilsus.
• Jälgige jõudlust: Jälgige oma micro-frontendide jõudlust, et tuvastada kitsaskohad ja optimeerida jõudlust.
• Automatiseerige juurutused: Automatiseerige juurutusprotsess, et tagada järjepidevad ja usaldusväärsed juurutused.
• Kasutage ühtset kodeerimisstiili: Jõustage ühtne kodeerimisstiil kõigis micro-frontendides, et parandada loetavust ja hooldatavust. Tööriistad nagu ESLint ja Prettier saavad sellega aidata.
• Dokumenteerige oma arhitektuur: Dokumenteerige oma micro-frontend arhitektuur, et tagada, et kõik meeskonnaliikmed mõistavad süsteemi ja selle toimimist.

Module Federation vs. teised Micro-Frontend lähenemised

Kuigi Module Federation on võimas tehnika micro-frontendide rakendamiseks, ei ole see ainus lähenemine. Teised populaarsed meetodid hõlmavad järgmist:

• Iframe'id: Iframe'id pakuvad tugevat isolatsiooni micro-frontendide vahel, kuid nende sujuv integreerimine võib olla keeruline ja neil võib olla jõudluse lisakulu.
• Veebikomponendid: Veebikomponendid võimaldavad teil luua korduvkasutatavaid UI elemente, mida saab kasutada erinevates micro-frontendides. Nende rakendamine võib aga olla keerulisem kui Module Federation'i puhul.
• Ehitusaegne integratsioon: See lähenemine hõlmab kõigi micro-frontendide ehitamist üheks rakenduseks ehitusajal. Kuigi see võib lihtsustada juurutamist, vähendab see meeskonna autonoomiat ja suurendab konfliktide riski.
• Single-SPA: Single-SPA on raamistik, mis võimaldab teil ühendada mitu ühe lehe rakendust üheks rakenduseks. See pakub paindlikumat lähenemist kui ehitusaegne integratsioon, kuid selle seadistamine võib olla keerulisem.

Valik, millist lähenemist kasutada, sõltub teie rakenduse spetsiifilistest nõuetest ning teie meeskonna suurusest ja struktuurist. Module Federation pakub head tasakaalu paindlikkuse, jõudluse ja kasutusmugavuse vahel, muutes selle paljude projektide jaoks populaarseks valikuks.

Module Federation'i näited reaalsest elust

Kuigi konkreetsete ettevõtete rakendused on sageli konfidentsiaalsed, rakendatakse Module Federation'i üldpõhimõtteid erinevates tööstusharudes ja stsenaariumides. Siin on mõned potentsiaalsed näited:

• E-kaubanduse platvormid: E-kaubanduse platvorm võiks kasutada Module Federation'i, et eraldada veebisaidi erinevad jaotised, nagu tootekataloog, ostukorv, kassaprotsess ja kasutajakonto haldus, eraldi micro-frontendideks. See võimaldab erinevatel meeskondadel nende jaotiste kallal iseseisvalt töötada ja uuendusi juurutada, mõjutamata ülejäänud platvormi. Näiteks võib meeskond *Saksamaal* keskenduda tootekataloogile, samal ajal kui meeskond *Indias* haldab ostukorvi.
• Finantsteenuste rakendused: Finantsteenuste rakendus võiks kasutada Module Federation'i tundlike funktsioonide, nagu kauplemisplatvormid ja kontohaldus, eraldamiseks eraldi micro-frontendideks. See suurendab turvalisust ja võimaldab nende kriitiliste komponentide sõltumatut auditeerimist. Kujutage ette meeskonda *Londonis*, mis on spetsialiseerunud kauplemisplatvormi funktsioonidele, ja teist meeskonda *New Yorgis*, mis tegeleb kontohaldusega.
• Sisuhaldussüsteemid (CMS): CMS võiks kasutada Module Federation'i, et võimaldada arendajatel luua ja juurutada kohandatud mooduleid micro-frontendidena. See võimaldab CMS-i kasutajatele suuremat paindlikkust ja kohandamist. Meeskond *Jaapanis* võiks ehitada spetsialiseeritud pildigalerii mooduli, samal ajal kui meeskond *Brasiilias* loob täiustatud tekstiredaktori.
• Tervishoiurakendused: Tervishoiurakendus võiks kasutada Module Federation'i erinevate süsteemide, nagu elektroonilised tervisekaardid (EHR-id), patsiendiportaalid ja arveldussüsteemid, integreerimiseks eraldi micro-frontendidena. See parandab koostalitlusvõimet ja võimaldab uute süsteemide lihtsamat integreerimist. Näiteks võiks meeskond *Kanadas* integreerida uue teletervishoiu mooduli, samal ajal kui meeskond *Austraalias* keskendub patsiendiportaali kogemuse parandamisele.

Kokkuvõte

Module Federation pakub võimsat ja paindlikku lähenemist micro-frontendide rakendamiseks. Võimaldades rakendustel dünaamiliselt üksteiselt koodi laadida käitusajal, võimaldab see luua tõeliselt sõltumatuid ja komponeeritavaid frontend-arhitektuure. Kuigi see nõuab hoolikat planeerimist ja rakendamist, muudavad suurenenud skaleeritavuse, kiiremate arendustsüklite ja suurema meeskonna autonoomia eelised selle mõjuvaks valikuks suurte ja keerukate veebirakenduste jaoks. Kuna veebiarenduse maastik areneb jätkuvalt, on Module Federationil potentsiaali mängida üha olulisemat rolli frontend-arhitektuuri tuleviku kujundamisel.

Mõistes selles artiklis kirjeldatud kontseptsioone ja parimaid praktikaid, saate kasutada Module Federation'i, et ehitada skaleeritavaid, hooldatavaid ja uuenduslikke frontend-rakendusi, mis vastavad tänapäeva kiire tempoga digitaalse maailma nõudmistele.