- Pakāpeniska migrācija ļauj komandām nožņaugt mantotus monolītus, aizstājot augstas vērtības lietotāja interfeisa fragmentus bez riskantas pilnīgas pārrakstīšanas.
- Organizatoriskā autonomija tiek panākts, saskaņojot mikrofrontendus ar uzņēmuma apakšdomēniem, nodrošinot neatkarīgus izvietošanas ciklus.
- Tehniskais sastāvs var apstrādāt, izmantojot servera puses fragmentus, moduļu federāciju vai izpildlaika JavaScript integrāciju atkarībā no veiktspējas vajadzībām.
Būsim reāli: lielākā daļa lielo uzņēmumu tīmekļa lietotņu būtībā ir milzīgas dubļu bumbas. Kad jums ir milzīga monolīta lietotāja saskarne, izstrādes mērogošana kļūst par murgu, jo visi viens otram kāpj kājām, un viena kļūda var izjaukt visu projektu. Pilnīgas pārrakstīšanas ideja ir vilinoša, taču reālajā pasaulē tā parasti ir pašnāvnieciska misija, kuras laikā paiet gadi, pirms lietotāji redz kaut vienu ieguvumu.
Tieši šeit izpaužas pakāpeniskas ieviešanas burvība . Tā vietā, lai veiktu izmaiņas, jūs sākat veidot monolītu pa daļām. Uztverot savu front-end kā neatkarīgi piegādājamu lietotņu kompozīciju, jūs varat modernizēt savu tehnoloģiju steku un dot iespēju savām komandām darboties ātrāk, bez stresa, kas saistīts ar augsta riska "lielā sprādziena" ieviešanu. Viss ir atkarīgs no tā, kā atrast optimālo līdzsvaru starp stabilitāti un elastību.
Fragmentu pīrsinga stratēģija
Viens no stilīgākajiem veidiem, kā apstrādāt mantotu pāreju, ir izmantot metodi, ko sauc par fragmentu caurduršanu . Iedomājieties, ka jums ir lēni ielādējama React lietotne; tā vietā, lai gaidītu, kamēr viss apvalks ielādēsies, varat atveidot servera puses fragmentus (izmantojot tādus rīkus kā Cloudflare Workers), kas ir interaktīvi gandrīz uzreiz. Šie fragmenti sākotnēji tiek ievietoti HTML augšējā līmenī un pēc tam "caurdurti" vai pārvietoti uz pareizo vietu DOM, kad mantotā čaula beidzot panāk.
Šī pieeja ir glābiņš Core Web Vitals uzlabošanai , jo tā samazina interaktivitātes laiku. Piemēram, jūs varētu pārvērst pieteikšanās veidlapu par atsevišķu fragmentu. Lietotāji var sākt rakstīt savus akreditācijas datus, pirms galvenā lietojumprogramma pat pastāv pārlūkprogrammā. Lai viss noritētu gludi, ziņojumu kopni var izmantot kā no ietvara neatkarīgu veidu, kā šie fragmenti var sazināties ar mantoto lietotni, neradot ciešu savienojumu.
Arhitektūras pieejas integrācijai
Atkarībā no jūsu mērķiem ir vairāki veidi, kā savienot šīs daļas kopā. Servera puses veidņu kompozīcija ir vecmodīga, bet uzticama metode, kurā HTML fragmentu ievietošanai tiek izmantotas tādas lietas kā Nginx. Ja vēlaties lielāku elastību, izpildlaika integrācija, izmantojot JavaScript, ļauj konteinera lietotnei lejupielādēt pakotni un izsaukt globālu renderēšanas funkciju. Tiem, kam patīk pārlūkprogrammas vietējās iespējas, tīmekļa komponenti piedāvā standartizētu veidu, kā definēt pielāgotus elementus, kurus čaula var vienkārši izveidot.
Mūsdienu darbnīcas arvien vairāk pievēršas moduļu federācijai . Tas ļauj lietojumprogrammai izpildes laikā dinamiski ielādēt moduļus no citas versijas. Izmantojot patērētāja un nodrošinātāja modeli , var koplietot atsevišķus elementus, piemēram, React vai Vue, lai lietotājam nebūtu piecas reizes jālejupielādē viens un tas pats ietvars. Tomēr zelta standarts, lai izvairītos no "atkarību elles", bieži vien ir monorepo , kas nodrošina, ka visas mikro-frontend sistēmas tiek pārbaudītas pret vienām un tām pašām bibliotēkas versijām pirms nonākšanas ražošanas vidē.
Izvairīšanās no bieži sastopamajām kļūmēm
Ir viegli pārspīlēt un radīt mikrofrontendija anarhiju . Bieži pieļauta kļūda ir domāt, ka mikrofrontendi ir tikai “lieli komponenti”. Poga ir komponents; norēķinu plūsma ir mikrofrontends. Ja sākat katru mazo lietotāja interfeisa elementu padarīt par atsevišķu izvietojamu elementu, jūs tikai pievienojat nevajadzīgu darbības sarežģītību . Jums vienmēr jāsaskaņo robežas ar uzņēmuma apakšdomēniem , nevis tehniskajiem slāņiem.
Vēl viens slazds ir vairāku ietvaru kārdinājums . Tas, ka varat palaist Angular, React un Svelte vienā lapā, nenozīmē, ka jums tas ir jādara. Tas samazina veiktspēju un fragmentē jūsu talantu kopumu. Vienīgais gadījums, kad tas ir jēgpilni, ir migrācijas stratēģijas laikā vai pēc iegādes. Lai novērstu lietotņu pārāk lielu sapīšanos, izvairieties no koplietota globāla stāvokļa. Tā vietā paļaujieties uz vienvirziena datu plūsmu un notikumu vadītu komunikāciju, lai komandas būtu patiesi autonomas.
Kompromiss: autonomija pretstatā virsizdevumiem
Arhitektūrā nav tādas lietas kā bezmaksas pusdienas. Izvēloties mikrofrontendus, jūs atomiskas versijas apmaināt pret neatkarīgām. Tas nozīmē, ka jūs varat saskarties ar versiju novirzi , kur dažādas lapas daļas darbina dažādas koplietotās bibliotēkas versijas. Jūs arī redzēsiet kopējā lietderīgās slodzes palielināšanos , ja neesat uzmanīgs ar koplietotajām atkarībām.
No organizatoriskā viedokļa jums būs nepieciešams vairāk CI/CD cauruļvadu un labāka novērojamība. Taču lielam uzņēmumam ieguvums ir milzīgs: samazināta kognitīvā slodze izstrādātājiem un iespēja izveidot jaunas komandas, kas var pārvaldīt funkciju no idejas līdz ražošanai. Ja konstatējat, ka vairākas mikrofrontend sistēmas darbojas ar vienu un to pašu API galapunktu, tā ir zīme, ka ir jāpārvērtē savas robežas vai jāievieš Backend-for-Frontend (BFF), lai apkopotu šos izsaukumus un novērstu API izplešanos.
