Frontend Micro-Frontend: Moduļu federācijas arhitektūras apgūšana

Mūsdienu strauji mainīgajā tīmekļa izstrādes ainavā liela mēroga frontend lietotņu veidošana un uzturēšana var kļūt arvien sarežģītāka. Tradicionālās monolītās arhitektūras bieži noved pie tādām problēmām kā koda uzpūšanās, lēni būvēšanas laiki un grūtības ar neatkarīgām izvietošanām. Micro-frontends piedāvā risinājumu, sadalot frontend mazākos, vieglāk pārvaldāmos gabalos. Šis raksts iedziļinās Moduļu federācijā (Module Federation) — spēcīgā tehnikā micro-frontends ieviešanai, izpētot tās priekšrocības, arhitektūru un praktiskās ieviešanas stratēģijas.

Kas ir Micro-Frontends?

Micro-frontends ir arhitektūras stils, kurā frontend lietotne tiek sadalīta mazākās, neatkarīgās un izvietojamās vienībās. Katrs micro-frontend parasti pieder atsevišķai komandai, kas nodrošina lielāku autonomiju un ātrākus izstrādes ciklus. Šī pieeja atspoguļo microservices arhitektūru, ko parasti izmanto backend pusē.

Galvenās micro-frontends iezīmes ietver:

• Neatkarīga izvietojamība: Katru micro-frontend var izvietot neatkarīgi, neietekmējot citas lietotnes daļas.
• Komandu autonomija: Dažādas komandas var pārvaldīt un izstrādāt dažādus micro-frontends, izmantojot sev vēlamos tehnoloģijas un darba plūsmas.
• Tehnoloģiju daudzveidība: Micro-frontends var veidot, izmantojot dažādus ietvarus un bibliotēkas, ļaujot komandām izvēlēties labākos rīkus konkrētajam darbam.
• Izolācija: Micro-frontends jābūt izolētiem vienam no otra, lai novērstu kaskādes kļūmes un nodrošinātu stabilitāti.

Kāpēc izmantot Micro-Frontends?

Micro-frontend arhitektūras pieņemšana piedāvā vairākas būtiskas priekšrocības, īpaši lielām un sarežģītām lietotnēm:

• Uzlabota mērogojamība: Sadalot frontend mazākās vienībās, ir vieglāk mērogot lietotni pēc vajadzības.
• Ātrāki izstrādes cikli: Neatkarīgas komandas var strādāt paralēli, kas noved pie ātrākiem izstrādes un izlaišanas cikliem.
• Palielināta komandu autonomija: Komandām ir lielāka kontrole pār savu kodu un tās var pieņemt lēmumus neatkarīgi.
• Vienkāršāka uzturēšana: Mazākas kodu bāzes ir vieglāk uzturēt un atkļūdot.
• Tehnoloģiski agnostiska: Komandas var izvēlēties labākās tehnoloģijas savām specifiskajām vajadzībām, ļaujot ieviest inovācijas un eksperimentēt.
• Samazināts risks: Izvietošanas ir mazākas un biežākas, samazinot liela mēroga kļūmju risku.

Ievads Moduļu federācijā

Moduļu federācija ir Webpack 5 ieviesta funkcija, kas ļauj JavaScript lietotnēm dinamiski ielādēt kodu no citām lietotnēm izpildes laikā. Tas nodrošina patiesi neatkarīgu un saliekamu micro-frontends izveidi. Tā vietā, lai visu būvētu vienā paketē, Moduļu federācija ļauj dažādām lietotnēm koplietot un patērēt viena otras moduļus, it kā tie būtu lokālas atkarības.

Atšķirībā no tradicionālajām micro-frontends pieejām, kas balstās uz iframes vai web komponentiem, Moduļu federācija nodrošina lietotājam viengabalaināku un integrētāku pieredzi. Tā izvairās no veiktspējas sloga un sarežģītības, kas saistīta ar šīm citām tehnikām.

Kā darbojas Moduļu federācija

Moduļu federācija darbojas pēc moduļu "atklāšanas" (exposing) un "patērēšanas" (consuming) principa. Viena lietotne ("resursdators" jeb "konteiners") var atklāt moduļus, kamēr citas lietotnes ("attālinātās") var patērēt šos atklātos moduļus. Lūk, procesa sadalījums:

1. Moduļa atklāšana: Micro-frontend, kas Webpack konfigurācijā ir iestatīts kā "attālināta" lietotne, atklāj noteiktus moduļus (komponentus, funkcijas, utilītas) caur konfigurācijas failu. Šī konfigurācija norāda moduļus, kas tiks koplietoti, un to attiecīgos ieejas punktus.
2. Moduļa patērēšana: Cits micro-frontend, kas konfigurēts kā "resursdators" jeb "konteiners", deklarē attālināto lietotni kā atkarību. Tas norāda URL, kur var atrast attālinātās lietotnes moduļu federācijas manifestu (mazs JSON fails, kas apraksta atklātos moduļus).
3. Izpildlaika atrisināšana: Kad resursdatora lietotnei nepieciešams izmantot moduli no attālinātās lietotnes, tā dinamiski ielādē attālinātās lietotnes moduļu federācijas manifestu. Pēc tam Webpack atrisina moduļa atkarību un ielādē nepieciešamo kodu no attālinātās lietotnes izpildes laikā.
4. Koda koplietošana: Moduļu federācija arī ļauj koplietot kodu starp resursdatora un attālinātajām lietotnēm. Ja abas lietotnes izmanto to pašu koplietotās atkarības versiju (piemēram, React, lodash), kods tiks koplietots, izvairoties no dublēšanās un samazinot pakešu izmērus.

Moduļu federācijas iestatīšana: praktisks piemērs

Ilustrēsim Moduļu federāciju ar vienkāršu piemēru, kurā iesaistīti divi micro-frontends: "Produktu katalogs" un "Iepirkumu grozs". Produktu katalogs atklās produktu saraksta komponentu, ko Iepirkumu grozs patērēs, lai parādītu saistītos produktus.

Projekta struktūra

  
  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
  

Produktu katalogs (Attālinātais)

webpack.config.js

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

  module.exports = {
    // ... citas webpack konfigurācijas
    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' },
        },
      }),
    ],
  };
  

Paskaidrojums:

• name: Attālinātās lietotnes unikālais nosaukums.
• filename: Atklātā ieejas punkta faila nosaukums. Šis fails satur moduļu federācijas manifestu.
• exposes: Definē, kuri moduļi tiks atklāti no šīs lietotnes. Šajā gadījumā mēs atklājam `ProductList` komponentu no `src/components/ProductList.jsx` ar nosaukumu `./ProductList`.
• shared: Norāda atkarības, kuras jākoplieto starp resursdatora un attālinātajām lietotnēm. Tas ir būtiski, lai izvairītos no koda dublēšanās un nodrošinātu saderību. `singleton: true` nodrošina, ka tiek ielādēta tikai viena koplietotās atkarības instance. `eager: true` ielādē koplietoto atkarību sākotnēji, kas var uzlabot veiktspēju. `requiredVersion` definē pieņemamo versiju diapazonu koplietotajai atkarībai.

src/components/ProductList.jsx

  
  import React from 'react';

  const ProductList = ({ products }) => (
    

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

  export default ProductList;
  

Iepirkumu grozs (Resursdators)

webpack.config.js

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

  module.exports = {
    // ... citas webpack konfigurācijas
    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' },
        },
      }),
    ],
  };
  

Paskaidrojums:

• name: Resursdatora lietotnes unikālais nosaukums.
• remotes: Definē attālinātās lietotnes, no kurām šī lietotne patērēs moduļus. Šajā gadījumā mēs deklarējam attālināto lietotni ar nosaukumu `product_catalog` un norādām URL, kur var atrast tās `remoteEntry.js` failu. Formāts ir `remoteName: 'remoteName@remoteEntryUrl'`.
• shared: Līdzīgi kā attālinātā lietotne, arī resursdatora lietotne definē savas koplietotās atkarības. Tas nodrošina, ka resursdatora un attālinātās lietotnes izmanto saderīgas koplietoto bibliotēku versijas.

src/components/RelatedProducts.jsx

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

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

    useEffect(() => {
      // Iegūstiet saistīto produktu datus (piemēram, no API)
      const fetchProducts = async () => {
        // Aizstājiet ar savu faktisko API galapunktu
        const response = await fetch('https://fakestoreapi.com/products?limit=3');
        const data = await response.json();
        setProducts(data);
      };

      fetchProducts();
    }, []);

    return (
      

        
Saistītie produkti
        {products.length > 0 ?  : 
Notiek ielāde...
}
      
    );
  };

  export default RelatedProducts;
  

Paskaidrojums:

• import ProductList from 'product_catalog/ProductList'; Šī rinda importē `ProductList` komponentu no `product_catalog` attālinātās lietotnes. Sintakse `remoteName/moduleName` norāda Webpack ielādēt moduli no norādītās attālinātās lietotnes.
• Pēc tam komponents izmanto importēto `ProductList` komponentu, lai parādītu saistītos produktus.

Piemēra palaišana

1. Palaidiet gan Produktu kataloga, gan Iepirkumu groza lietotnes, izmantojot to attiecīgos izstrādes serverus (piemēram, `npm start`). Pārliecinieties, ka tās darbojas uz dažādiem portiem (piemēram, Produktu katalogs uz porta 3001 un Iepirkumu grozs uz porta 3000).
2. Atveriet pārlūkprogrammā Iepirkumu groza lietotni.
3. Jums vajadzētu redzēt sadaļu "Saistītie produkti", ko renderē `ProductList` komponents no Produktu kataloga lietotnes.

Padziļināti Moduļu federācijas koncepti

Papildus pamata iestatīšanai Moduļu federācija piedāvā vairākas papildu funkcijas, kas var uzlabot jūsu micro-frontend arhitektūru:

Koda koplietošana un versiju pārvaldība

Kā parādīts piemērā, Moduļu federācija ļauj koplietot kodu starp resursdatora un attālinātajām lietotnēm. To panāk, izmantojot `shared` konfigurācijas opciju Webpack. Norādot koplietotās atkarības, jūs varat izvairīties no koda dublēšanās un samazināt pakešu izmērus. Pareiza koplietoto atkarību versiju pārvaldība ir būtiska, lai nodrošinātu saderību un novērstu konfliktus. Semantiskā versiju numerācija (SemVer) ir plaši izmantots standarts programmatūras versiju pārvaldībai, kas ļauj definēt saderīgus versiju diapazonus (piemēram, `^17.0.0` atļauj jebkuru versiju, kas ir lielāka vai vienāda ar 17.0.0, bet mazāka par 18.0.0).

Dinamiskie attālinātie moduļi

Iepriekšējā piemērā attālinātās lietotnes URL tika fiksēti iekodēts `webpack.config.js` failā. Tomēr daudzos reālos scenārijos jums var būt nepieciešams dinamiski noteikt attālināto URL izpildes laikā. To var panākt, izmantojot uz solījumiem (promise) balstītu attālināto konfigurāciju:

  
  // webpack.config.js
  remotes: {
    product_catalog: new Promise(resolve => {
      // Iegūstiet attālināto URL no konfigurācijas faila vai API
      fetch('/config.json')
        .then(response => response.json())
        .then(config => {
          const remoteUrl = config.productCatalogUrl;
          resolve(`product_catalog@${remoteUrl}/remoteEntry.js`);
        });
    }),
  },
  

Tas ļauj konfigurēt attālināto URL, pamatojoties uz vidi (piemēram, izstrāde, testēšana, produkcija) vai citiem faktoriem.

Asinhrona moduļu ielāde

Moduļu federācija atbalsta asinhronu moduļu ielādi, ļaujot ielādēt moduļus pēc pieprasījuma. Tas var uzlabot jūsu lietotnes sākotnējo ielādes laiku, atliekot nekritisko moduļu ielādi.

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

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

  const RelatedProducts = () => {
    return (
      

        
Saistītie produkti
        Notiek ielāde...
}> 
          
        
      
    );
  };
  

Izmantojot `React.lazy` un `Suspense`, jūs varat asinhroni ielādēt `ProductList` komponentu no attālinātās lietotnes. `Suspense` komponents nodrošina rezerves lietotāja saskarni (piemēram, ielādes indikatoru), kamēr modulis tiek ielādēts.

Federētie stili un resursi

Moduļu federāciju var izmantot arī, lai koplietotu stilus un resursus starp micro-frontends. Tas var palīdzēt uzturēt konsekventu izskatu un sajūtu visā jūsu lietotnē.

Lai koplietotu stilus, jūs varat atklāt CSS moduļus vai stilizētus komponentus no attālinātās lietotnes. Lai koplietotu resursus (piemēram, attēlus, fontus), varat konfigurēt Webpack, lai kopētu resursus uz koplietotu atrašanās vietu un pēc tam atsauktos uz tiem no resursdatora lietotnes.

Labākās prakses Moduļu federācijai

Ieviešot Moduļu federāciju, ir svarīgi ievērot labākās prakses, lai nodrošinātu veiksmīgu un uzturējamu arhitektūru:

• Definējiet skaidras robežas: Skaidri definējiet robežas starp micro-frontends, lai izvairītos no ciešas sasaistes un nodrošinātu neatkarīgu izvietojamību.
• Izveidojiet komunikācijas protokolus: Definējiet skaidrus komunikācijas protokolus starp micro-frontends. Apsveriet iespēju izmantot notikumu kopnes (event buses), koplietotas stāvokļa pārvaldības bibliotēkas vai pielāgotus API.
• Rūpīgi pārvaldiet koplietotās atkarības: Rūpīgi pārvaldiet koplietotās atkarības, lai izvairītos no versiju konfliktiem un nodrošinātu saderību. Izmantojiet semantisko versiju numerāciju un apsveriet atkarību pārvaldības rīku, piemēram, npm vai yarn, izmantošanu.
• Ieviesiet robustu kļūdu apstrādi: Ieviesiet robustu kļūdu apstrādi, lai novērstu kaskādes kļūmes un nodrošinātu jūsu lietotnes stabilitāti.
• Pārraugiet veiktspēju: Pārraugiet savu micro-frontends veiktspēju, lai identificētu vājās vietas un optimizētu veiktspēju.
• Automatizējiet izvietošanu: Automatizējiet izvietošanas procesu, lai nodrošinātu konsekventas un uzticamas izvietošanas.
• Izmantojiet konsekventu kodēšanas stilu: Ieviesiet konsekventu kodēšanas stilu visos micro-frontends, lai uzlabotu lasāmību un uzturējamību. Rīki, piemēram, ESLint un Prettier, var palīdzēt šajā jautājumā.
• Dokumentējiet savu arhitektūru: Dokumentējiet savu micro-frontend arhitektūru, lai nodrošinātu, ka visi komandas locekļi saprot sistēmu un tās darbību.

Moduļu federācija salīdzinājumā ar citām Micro-Frontend pieejām

Lai gan Moduļu federācija ir spēcīga tehnika micro-frontends ieviešanai, tā nav vienīgā pieeja. Citas populāras metodes ietver:

• Iframes: Iframes nodrošina spēcīgu izolāciju starp micro-frontends, bet tos var būt grūti integrēt viengabalaini, un tie var radīt veiktspējas slogu.
• Web Components: Web komponenti ļauj izveidot atkārtoti lietojamus lietotāja saskarnes elementus, ko var izmantot dažādos micro-frontends. Tomēr tos var būt sarežģītāk ieviest nekā Moduļu federāciju.
• Būvēšanas laika integrācija: Šī pieeja ietver visu micro-frontends būvēšanu vienā lietotnē būvēšanas laikā. Lai gan tas var vienkāršot izvietošanu, tas samazina komandu autonomiju un palielina konfliktu risku.
• Single-SPA: Single-SPA ir ietvars, kas ļauj apvienot vairākas vienas lapas lietotnes (single-page applications) vienā lietotnē. Tas nodrošina elastīgāku pieeju nekā būvēšanas laika integrācija, bet var būt sarežģītāk iestatāms.

Izvēle, kuru pieeju izmantot, ir atkarīga no jūsu lietotnes specifiskajām prasībām un jūsu komandas lieluma un struktūras. Moduļu federācija piedāvā labu līdzsvaru starp elastību, veiktspēju un lietošanas ērtumu, padarot to par populāru izvēli daudziem projektiem.

Moduļu federācijas piemēri reālajā dzīvē

Lai gan konkrētu uzņēmumu implementācijas bieži ir konfidenciālas, Moduļu federācijas vispārīgie principi tiek pielietoti dažādās nozarēs un scenārijos. Šeit ir daži potenciāli piemēri:

• E-komercijas platformas: E-komercijas platforma varētu izmantot Moduļu federāciju, lai atdalītu dažādas tīmekļa vietnes sadaļas, piemēram, produktu katalogu, iepirkumu grozu, norēķinu procesu un lietotāja konta pārvaldību, atsevišķos micro-frontends. Tas ļauj dažādām komandām strādāt pie šīm sadaļām neatkarīgi un izvietot atjauninājumus, neietekmējot pārējo platformu. Piemēram, komanda *Vācijā* varētu koncentrēties uz produktu katalogu, kamēr komanda *Indijā* pārvalda iepirkumu grozu.
• Finanšu pakalpojumu lietotnes: Finanšu pakalpojumu lietotne varētu izmantot Moduļu federāciju, lai izolētu sensitīvas funkcijas, piemēram, tirdzniecības platformas un kontu pārvaldību, atsevišķos micro-frontends. Tas uzlabo drošību un ļauj neatkarīgi auditēt šos kritiskos komponentus. Iedomājieties, ka komanda *Londonā* specializējas tirdzniecības platformas funkcijās, un cita komanda *Ņujorkā* nodarbojas ar kontu pārvaldību.
• Satura pārvaldības sistēmas (CMS): CMS varētu izmantot Moduļu federāciju, lai ļautu izstrādātājiem izveidot un izvietot pielāgotus moduļus kā micro-frontends. Tas nodrošina lielāku elastību un pielāgošanas iespējas CMS lietotājiem. Komanda *Japānā* varētu izveidot specializētu attēlu galerijas moduli, kamēr komanda *Brazīlijā* veido uzlabotu teksta redaktoru.
• Veselības aprūpes lietotnes: Veselības aprūpes lietotne varētu izmantot Moduļu federāciju, lai integrētu dažādas sistēmas, piemēram, elektroniskos veselības ierakstus (EHR), pacientu portālus un norēķinu sistēmas, kā atsevišķus micro-frontends. Tas uzlabo sadarbspēju un ļauj vieglāk integrēt jaunas sistēmas. Piemēram, komanda *Kanādā* varētu integrēt jaunu telemedicīnas moduli, kamēr komanda *Austrālijā* koncentrējas uz pacientu portāla pieredzes uzlabošanu.

Noslēgums

Moduļu federācija nodrošina spēcīgu un elastīgu pieeju micro-frontends ieviešanai. Ļaujot lietotnēm dinamiski ielādēt kodu vienai no otras izpildes laikā, tā nodrošina patiesi neatkarīgu un saliekamu frontend arhitektūru izveidi. Lai gan tas prasa rūpīgu plānošanu un ieviešanu, ieguvumi, piemēram, palielināta mērogojamība, ātrāki izstrādes cikli un lielāka komandu autonomija, padara to par pārliecinošu izvēli lielām un sarežģītām tīmekļa lietotnēm. Tā kā tīmekļa izstrādes ainava turpina attīstīties, Moduļu federācija ir gatava spēlēt arvien nozīmīgāku lomu frontend arhitektūras nākotnes veidošanā.

Izprotot šajā rakstā izklāstītos jēdzienus un labākās prakses, jūs varat izmantot Moduļu federāciju, lai veidotu mērogojamas, uzturējamas un inovatīvas frontend lietotnes, kas atbilst mūsdienu straujās digitālās pasaules prasībām.