Frontend Mikro-Frontend Maršrutētājs: Pielietojumu Pārlūkošana

Mūsdienu tīmekļa izstrādē mikro-frontend arhitektūra ir guvusi ievērojamu popularitāti kā veids, kā izveidot lielas, sarežģītas lietojumprogrammas. Tā ietver monolītiska frontenda sadalīšanu mazākās, neatkarīgās un izvietojamās vienībās (mikro-frontendos). Viens no galvenajiem izaicinājumiem šajā arhitektūrā ir starpprogrammu navigācijas pārvaldība, kas ļauj lietotājiem nemanāmi pārvietoties starp šiem neatkarīgajiem mikro-frontendiem. Šis raksts sniedz visaptverošu ceļvedi frontend mikro-frontend maršrutēšanai un starpprogrammu navigācijai.

Kas ir Mikro-Frontendi?

Mikro-frontendi ir arhitektūras stils, kurā neatkarīgi piegādājamas frontend lietojumprogrammas tiek apvienotas vienotā, saskaņotā lietotāja pieredzē. Tas ir līdzīgi mikroservisiem backendā. Katrs mikro-frontends parasti pieder atsevišķai komandai, kas nodrošina lielāku autonomiju, ātrākus izstrādes ciklus un vieglāku uzturēšanu. Mikro-frontendu priekšrocības ietver:

• Neatkarīga izvietošana: Komandas var izvietot savus mikro-frontendus, neietekmējot citas lietojumprogrammas daļas.
• Tehnoloģiju daudzveidība: Dažādus mikro-frontendus var izveidot, izmantojot dažādas tehnoloģijas, ļaujot komandām izvēlēties labāko rīku darbam. Piemēram, viena komanda var izmantot React, bet cita - Vue.js vai Angular.
• Mērogojamība: Lietojumprogrammu var mērogot vieglāk, jo katru mikro-frontendu var mērogot neatkarīgi.
• Uzlabota uzturamība: Mazākas koda bāzes ir vieglāk saprast un uzturēt.
• Komandas autonomija: Komandām ir lielāka kontrole pār savu kodu un izstrādes procesu.

Nepieciešamība pēc Mikro-Frontend Maršrutētāja

Bez labi definētas maršrutēšanas stratēģijas lietotāji, pārvietojoties starp mikro-frontendiem, saskarsies ar nesaskaņotu un nomācošu pieredzi. Mikro-frontend maršrutētājs to risina, nodrošinot centralizētu mehānismu navigācijas pārvaldībai visā lietojumprogrammā. Tas ietver:

• URL pārvaldība: Nodrošināt, ka URL precīzi atspoguļo lietotāja pašreizējo atrašanās vietu lietojumprogrammā.
• Stāvokļa pārvaldība: Nepieciešamības gadījumā koplietot stāvokli starp mikro-frontendiem.
• Slinka ielāde: Ielādēt mikro-frontendus tikai tad, kad tie ir nepieciešami, lai uzlabotu veiktspēju.
• Autentifikācija un autorizācija: Pārvaldīt lietotāju autentifikāciju un autorizāciju dažādos mikro-frontendos.

Starpprogrammu Navigācijas Stratēģijas

Ir vairākas pieejas starpprogrammu navigācijas ieviešanai mikro-frontend arhitektūrā. Katrai pieejai ir savas priekšrocības un trūkumi, un labākā izvēle ir atkarīga no jūsu lietojumprogrammas specifiskajām prasībām.

1. Centralizēta Maršrutētāja Izmantošana (Single-Spa)

Single-Spa ir populārs ietvars mikro-frontendu veidošanai. Tas izmanto centralizētu maršrutētāju, lai pārvaldītu navigāciju starp dažādām lietojumprogrammām. Galvenā lietojumprogramma darbojas kā organizators un ir atbildīga par mikro-frontendu renderēšanu un atvienošanu, pamatojoties uz pašreizējo URL.

Kā tas darbojas:

1. Lietotājs pāriet uz noteiktu URL.
2. Single-spa maršrutētājs pārtver URL izmaiņas.
3. Pamatojoties uz URL, maršrutētājs nosaka, kuram mikro-frontendam jābūt aktīvam.
4. Maršrutētājs aktivizē atbilstošo mikro-frontendu un atvieno visus citus aktīvos mikro-frontendus.

Piemērs (Single-Spa):

Pieņemsim, ka jums ir trīs mikro-frontendi: home, products un cart. Single-spa maršrutētājs tiktu konfigurēts šādi:

import { registerApplication, start } from 'single-spa'; registerApplication( 'home', () => import('./home/home.app.js'), location => location.pathname === '/' ); registerApplication( 'products', () => import('./products/products.app.js'), location => location.pathname.startsWith('/products') ); registerApplication( 'cart', () => import('./cart/cart.app.js'), location => location.pathname.startsWith('/cart') ); start();

Šajā piemērā katrs mikro-frontends ir reģistrēts ar single-spa, un tiek nodrošināta funkcija, lai noteiktu, kad mikro-frontendam jābūt aktīvam, pamatojoties uz URL. Kad lietotājs pāriet uz /products, tiks aktivizēts products mikro-frontends.

Priekšrocības:

• Centralizēta kontrole pār maršrutēšanu.
• Vienkāršota stāvokļa pārvaldība (var pārvaldīt single-spa organizators).
• Viegli integrējams ar esošām lietojumprogrammām.

Trūkumi:

• Viena atteices punkts. Ja organizators nedarbojas, tiek ietekmēta visa lietojumprogramma.
• Var kļūt par veiktspējas vājvietu, ja netiek ieviests efektīvi.

2. Moduļu Federācija (Webpack 5)

Webpack 5 Moduļu Federācija ļauj koplietot kodu starp dažādiem Webpack būvējumiem izpildlaikā. Tas nozīmē, ka jūs varat atklāt komponentus, moduļus vai pat veselas lietojumprogrammas no viena būvējuma (host) citam (remote). Tas atvieglo mikro-frontendu veidošanu, kur katrs mikro-frontends ir atsevišķs Webpack būvējums.

Kā tas darbojas:

1. Katrs mikro-frontends tiek veidots kā atsevišķs Webpack projekts.
2. Viens mikro-frontends tiek norādīts kā host lietojumprogramma.
3. Host lietojumprogramma definē, kurus moduļus tā vēlas patērēt no remote mikro-frontendiem.
4. Remote mikro-frontendi definē, kurus moduļus tie vēlas atklāt host lietojumprogrammai.
5. Izpildlaikā host lietojumprogramma ielādē atklātos moduļus no remote mikro-frontendiem pēc vajadzības.

Piemērs (Moduļu Federācija):

Pieņemsim, ka ir host lietotne un remote lietotne.

host/webpack.config.js:

const { ModuleFederationPlugin } = require('webpack').container; module.exports = { // ... plugins: [ new ModuleFederationPlugin({ name: 'host', remotes: { remote: 'remote@http://localhost:3001/remoteEntry.js', }, shared: ['react', 'react-dom'], }), ], };

remote/webpack.config.js:

const { ModuleFederationPlugin } = require('webpack').container; module.exports = { // ... plugins: [ new ModuleFederationPlugin({ name: 'remote', exposes: { './Button': './src/Button', }, shared: ['react', 'react-dom'], }), ], };

Šajā piemērā host lietojumprogramma patērē Button komponentu no remote lietojumprogrammas. shared opcija nodrošina, ka abas lietojumprogrammas izmanto vienu un to pašu react un react-dom versiju.

Priekšrocības:

• Decentralizēta arhitektūra. Katrs mikro-frontends ir neatkarīgs, un to var izstrādāt un izvietot atsevišķi.
• Koda koplietošana. Moduļu Federācija ļauj koplietot kodu starp dažādām lietojumprogrammām izpildlaikā.
• Slinka ielāde. Moduļi tiek ielādēti tikai tad, kad tie ir nepieciešami, uzlabojot veiktspēju.

Trūkumi:

• Sarežģītāk iestatīt un konfigurēt nekā single-spa.
• Nepieciešama rūpīga koplietošanas atkarību pārvaldība, lai izvairītos no versiju konfliktiem.

3. Tīmekļa Komponenti

Tīmekļa Komponenti ir tīmekļa standartu kopums, kas ļauj izveidot atkārtoti izmantojamus pielāgotus HTML elementus. Šos komponentus var izmantot jebkurā tīmekļa lietojumprogrammā neatkarīgi no izmantotā ietvara. Tas padara tos par dabisku risinājumu mikro-frontend arhitektūrām, jo tie nodrošina tehnoloģiski agnostisku veidu, kā veidot un koplietot UI komponentus.

Kā tas darbojas:

1. Katrs mikro-frontends atklāj savu UI kā tīmekļa komponentu kopumu.
2. Galvenā lietojumprogramma (vai cits mikro-frontends) patērē šos tīmekļa komponentus, importējot tos un izmantojot tos savā HTML.
3. Tīmekļa Komponenti pārvalda savu renderēšanu un loģiku.

Piemērs (Tīmekļa Komponenti):

micro-frontend-a.js:

class MyComponent extends HTMLElement { constructor() { super(); this.attachShadow({ mode: 'open' }); this.shadowRoot.innerHTML = `

Hello from Micro-Frontend A!

`; } } customElements.define('micro-frontend-a', MyComponent);

index.html (galvenā lietojumprogramma):

Main Application

Šajā piemērā fails micro-frontend-a.js definē tīmekļa komponentu ar nosaukumu micro-frontend-a. Fails index.html importē šo failu un izmanto tīmekļa komponentu savā HTML. Pārlūkprogramma renderēs tīmekļa komponentu, parādot "Hello from Micro-Frontend A!".

Priekšrocības:

• Tehnoloģiski agnostisks. Tīmekļa Komponentus var izmantot ar jebkuru ietvaru vai bez ietvara.
• Atkārtoti izmantojams. Tīmekļa Komponentus var viegli atkārtoti izmantot dažādās lietojumprogrammās.
• Iekapsulēšana. Tīmekļa Komponenti iekapsulē savus stilus un loģiku, novēršot konfliktus ar citām lietojumprogrammas daļām.

Trūkumi:

• Var būt detalizētāks ieviešanā nekā citas pieejas.
• Var būt nepieciešami polyfill, lai atbalstītu vecākas pārlūkprogrammas.

4. Iframe

Iframe (Inline Frames) ir vecāka, bet joprojām dzīvotspējīga iespēja mikro-frontendu izolēšanai. Katrs mikro-frontends darbojas savā iframe, nodrošinot augstu izolācijas pakāpi. Saziņu starp iframe var panākt, izmantojot postMessage API.

Kā tas darbojas:

1. Katrs mikro-frontends tiek izvietots kā atsevišķa tīmekļa lietojumprogramma.
2. Galvenā lietojumprogramma iekļauj katru mikro-frontendu iframe.
3. Saziņa starp galveno lietojumprogrammu un mikro-frontendiem tiek veikta, izmantojot postMessage API.

Piemērs (Iframe):

index.html (galvenā lietojumprogramma):

Main Application

Šajā piemērā fails index.html iekļauj divus iframe, katrs no tiem norāda uz citu mikro-frontendu.

Priekšrocības:

• Augsta izolācijas pakāpe. Mikro-frontendi ir pilnībā izolēti viens no otra, novēršot konfliktus.
• Viegli ieviešams. Iframe ir vienkārša un labi saprotama tehnoloģija.

Trūkumi:

• Var būt grūti sazināties starp iframe.
• Var rasties veiktspējas problēmas, jo ir daudz iframe.
• Slikta lietotāja pieredze, jo trūkst nemanāmas integrācijas.

Stāvokļa Pārvaldība Starp Mikro-Frontendiem

Stāvokļa pārvaldība starp mikro-frontendiem ir kritisks starpprogrammu navigācijas aspekts. Var izmantot vairākas stratēģijas:

• URL bāzes stāvoklis: Stāvokļa kodēšana URL. Šī pieeja padara lietojumprogrammas stāvokli koplietojamu, izmantojot URL, un viegli grāmatzīmējumu.
• Centralizēta stāvokļa pārvaldība (Redux, Vuex): Globālas stāvokļa pārvaldības bibliotēkas izmantošana, lai koplietotu stāvokli starp mikro-frontendiem. Tas ir īpaši noderīgi sarežģītām lietojumprogrammām ar ievērojamu koplietojamu stāvokli.
• Pielāgoti notikumi: Pielāgotu notikumu izmantošana, lai sazinātos par stāvokļa izmaiņām starp mikro-frontendiem. Šī pieeja nodrošina vāju saikni starp mikro-frontendiem.
• Pārlūkprogrammas krātuve (LocalStorage, SessionStorage): Stāvokļa saglabāšana pārlūkprogrammas krātuvē. Šī pieeja ir piemērota vienkāršam stāvoklim, kas nav jākoplieto starp visiem mikro-frontendiem. Tomēr ņemiet vērā drošības apsvērumus, saglabājot sensitīvus datus.

Autentifikācija un Autorizācija

Autentifikācija un autorizācija ir būtiski jebkuras tīmekļa lietojumprogrammas aspekti, un tie kļūst vēl svarīgāki mikro-frontend arhitektūrā. Parastās pieejas ietver:

• Centralizēts autentifikācijas pakalpojums: Īpašs pakalpojums apstrādā lietotāju autentifikāciju un izsniedz žetonus (piemēram, JWT). Pēc tam mikro-frontendi var validēt šos žetonus, lai noteiktu lietotāja autorizāciju.
• Koplietojams autentifikācijas modulis: Koplietojams modulis ir atbildīgs par autentifikācijas loģikas apstrādi. Šo moduli var izmantot visi mikro-frontendi.
• Edge autentifikācija: Autentifikācija tiek apstrādāta tīkla malā (piemēram, izmantojot apgriezto starpniekserveri vai API vārteju). Šī pieeja var vienkāršot autentifikācijas loģiku mikro-frontendos.

Labākā Prakse Mikro-Frontend Maršrutēšanai

Šeit ir daži ieteikumi, kas jāpatur prātā, ieviešot mikro-frontend maršrutēšanu:

• Saglabājiet to vienkāršu: Izvēlieties vienkāršāko maršrutēšanas stratēģiju, kas atbilst jūsu vajadzībām.
• Atdaliet Mikro-Frontendus: Samaziniet atkarības starp mikro-frontendiem, lai veicinātu neatkarīgu izstrādi un izvietošanu.
• Izmantojiet konsekventu URL struktūru: Uzturiet konsekventu URL struktūru visos mikro-frontendos, lai uzlabotu lietotāja pieredzi un SEO.
• Ieviesiet slinku ielādi: Ielādējiet mikro-frontendus tikai tad, kad tie ir nepieciešami, lai uzlabotu veiktspēju.
• Uzraugiet veiktspēju: Regulāri uzraugiet mikro-frontend lietojumprogrammas veiktspēju, lai identificētu un novērstu jebkādus vājpunktus.
• Izveidojiet skaidrus saziņas kanālus: Nodrošiniet, lai komandām, kas strādā pie dažādiem mikro-frontendiem, būtu skaidri saziņas kanāli, lai koordinētu izstrādes centienus un atrisinātu jebkādus integrācijas jautājumus.
• Ieviesiet robustu kļūdu apstrādi: Ieviesiet robustu kļūdu apstrādi, lai graciozi apstrādātu kļūmes atsevišķos mikro-frontendos un neļautu tām ietekmēt visu lietojumprogrammu.
• Automatizēta testēšana: Ieviesiet visaptverošu automatizētu testēšanu, tostarp vienību testus, integrācijas testus un pilnus testus, lai nodrošinātu mikro-frontend lietojumprogrammas kvalitāti un stabilitāti.

Secinājums

Mikro-frontend maršrutēšana ir sarežģīts, bet būtisks aspekts mērogojamu un uzturamu tīmekļa lietojumprogrammu izveidei. Rūpīgi apsverot dažādās maršrutēšanas stratēģijas un labāko praksi, kas izklāstīta šajā rakstā, jūs varat izveidot nemanāmu un lietotājam draudzīgu pieredzi saviem lietotājiem. Pareizas pieejas izvēle neatkarīgi no tā, vai tas ir centralizēts maršrutētājs, piemēram, Single-Spa, Moduļu Federācija, Tīmekļa Komponenti vai pat Iframe, ir atkarīga no jūsu specifiskajām vajadzībām un prioritātēm. Atcerieties par prioritāti atdalīšanai, konsekventām URL struktūrām un veiktspējas optimizācijai. Ieviešot labi izstrādātu maršrutēšanas stratēģiju, jūs varat atraisīt visu mikro-frontend arhitektūras potenciālu un izveidot patiesi izcilas tīmekļa lietojumprogrammas globālai auditorijai.