- Järkjärguline migratsioon võimaldab meeskondadel lämmatada vananenud monoliite, asendades väärtuslikke kasutajaliidese fragmente ilma riskantsete täielike ümberkirjutusteta.
- Organisatsiooniline autonoomia saavutatakse mikro-esipaneelide ja ärialamdomeenide joondamise teel, võimaldades sõltumatuid juurutustsükleid.
- Tehniline koostis saab olenevalt jõudlusvajadustest hallata serveripoolsete fragmentide, moodulite föderatsiooni või JavaScripti integratsiooni kaudu.
Olgem ausad: enamik suuri ettevõtte veebirakendusi on sisuliselt hiiglaslikud mudapallid. Kui sul on tohutu monoliitne kasutajaliides, muutub arenduse skaleerimine õudusunenäoks, sest kõik astuvad üksteisele varvastele ja üksainus viga võib kogu ettevõtmise nurjata. Täieliku ümberkirjutamise idee on ahvatlev, kuid tegelikkuses on see tavaliselt enesetapumissioon, mis võtab aastaid, enne kui kasutajad näevad mingit kasu.
Siin tulebki mängu järkjärgulise kasutuselevõtu võlu . Selle asemel, et lihtsalt ümber lülituda, hakkad monoliiti tükkhaaval välja töötama. Koheldes oma esiserverit iseseisvalt tarnitavate rakenduste kompositsioonina, saad oma tehnoloogiaplatvormi kaasajastada ja anda oma meeskondadele võimaluse kiiremini tegutseda ilma riskantse suure pauguga juurutamise stressita. Asi on stabiilsuse ja paindlikkuse vahelise tasakaalu leidmises.
Fragmentide augustamise strateegia
Üks lahedamaid viise pärandülemineku käsitlemiseks on fragmentide läbitorkamise tehnika . Kujutage ette, et teil on aeglaselt laadiv Reacti rakendus; selle asemel, et oodata kogu kesta käivitumist, saate renderdada serveripoolseid fragmente (kasutades selliseid tööriistu nagu Cloudflare Workers), mis on peaaegu koheselt interaktiivsed. Need fragmendid paigutatakse algselt HTML-i kõrgeimale tasemele ja seejärel "läbistatakse" ehk liigutatakse DOM-is õigesse kohta, kui pärandkest lõpuks järele jõuab.
See lähenemisviis on Core Web Vitalsi täiustamisel elupäästja, kuna see vähendab interaktiivsusele kuluvat aega. Näiteks võiksite muuta sisselogimisvormi eraldiseisvaks fragmendiks. Kasutajad saavad hakata oma volitusi sisestama juba enne, kui põhirakendus brauseris üldse olemas on . Sujuvuse tagamiseks saab sõnumisiini kasutada raamistikust sõltumatu viisina, kuidas need fragmendid saavad pärandrakendusega suhelda ilma tihedat sidet loomata.
Arhitektuurilised lähenemisviisid integratsioonile
Sõltuvalt teie eesmärkidest on nende elementide kokkupanekuks mitu võimalust. Serveripoolne malli koostamine on vanamoodne, kuid usaldusväärne meetod, mis kasutab HTML-fragmentide lisamiseks selliseid asju nagu Nginx. Kui soovite suuremat paindlikkust, võimaldab JavaScripti kaudu töötav integratsioon konteinerrakendusel alla laadida paketi ja kutsuda globaalse renderdusfunktsiooni. Neile, kellele meeldivad brauseri loomulikud võimalused, pakuvad veebikomponendid standardiseeritud viisi kohandatud elementide määratlemiseks, mida kest saab lihtsalt luua.
Tänapäevased tarkvaraarenduskeskused kalduvad üha enam moodulite föderatsiooni poole . See võimaldab rakendusel käitusajal dünaamiliselt laadida mooduleid teisest järgust. Tarbija ja pakkuja mudeli abil saab jagada üksikkomponente nagu React või Vue, nii et kasutaja ei pea sama raamistikku viis korda alla laadima. „Sõltuvuspõrgu” vältimiseks on aga sageli kuldstandardiks monorepo , mis tagab, et kõiki mikro-front-end'e testitakse enne tootmiskeskkonda jõudmist samade teekide versioonide suhtes.
Levinud lõksude vältimine
Lihtne on liiale minna ja mikro-esiliidese anarhiat tekitada . Levinud viga on arvata, et mikro-esiliidesed on lihtsalt „suured komponendid“. Nupp on komponent; kassavoog on mikro-esikülg. Kui hakkate iga pisikest kasutajaliidese elementi eraldi juurutatavaks tegema, lisate lihtsalt tarbetut operatiivset keerukust . Peaksite oma piirid alati ühtlustama ettevõtte alamdomeenidega , mitte tehniliste kihtidega.
Teine lõks on mitmeraamistiku kiusatus . See, et saate Angularit, Reacti ja Svelte'i ühel lehel käitada, ei tähenda, et peaksite seda tegema. See vähendab jõudlust ja killustab teie talentide reservi. Ainus kord, kui see on mõttekas, on migratsioonistrateegia ajal või pärast omandamist. Rakenduste liigse põimumise vältimiseks vältige jagatud globaalset olekut. Selle asemel toetuge ühesuunalisele andmevoogule ja sündmustepõhisele suhtlusele, et hoida meeskonnad tõeliselt autonoomsetena.
Kompromiss: autonoomia vs üldkulud
Arhitektuuris tasuta lõunat pole olemas. Mikro-front-end'ide valimisega vahetad aatomiversioonid sõltumatute vastu. See tähendab, et võid tegeleda versioonikaldega , kus lehe erinevad osad käitavad jagatud teegi erinevaid versioone. Samuti näed kogumahu suurenemist, kui sa ei ole oma jagatud sõltuvustega ettevaatlik.
Organisatsioonilisest vaatenurgast vajate rohkem CI/CD torustikke ja paremat jälgitavust. Suure ettevõtte jaoks on aga kasu tohutu: arendajate kognitiivne koormus väheneb ja võimalus luua uusi meeskondi, kes saavad funktsiooni ideest tootmiseni omada. Kui leiate, et mitu mikro-frontendi töötavad sama API lõpp-punkti kallal, on see märk piiride ümberhindamisest või frontendi-backendi (BFF) kasutuselevõtust, et koondada need kõned ja vältida API laialivalgumist.
