- Lisääntyvä migraatio antaa tiimeille mahdollisuuden kuristaa vanhoja monoliitteja korvaamalla arvokkaita käyttöliittymäfragmentteja ilman riskialttiita täydellisiä uudelleenkirjoituksia.
- Organisaation autonomia saavutetaan yhdenmukaistamalla mikrokäyttöliittymät liiketoiminnan aliverkkotunnuksiin, mikä mahdollistaa itsenäiset käyttöönottosyklit.
- Tekninen koostumus voidaan käsitellä palvelinpuolen fragmenttien, moduuliliiton tai ajonaikaisen JavaScript-integraation kautta suorituskykytarpeista riippuen.
Ollaanpa rehellisiä: useimmat valtavat yritystason verkkosovellukset ovat pohjimmiltaan jättimäisiä mutapalleja. Kun käyttöliittymä on massiivinen ja monoliittinen, kehityksen skaalaamisesta tulee painajainen, koska kaikki astuvat toistensa varpaille ja yksittäinen bugi voi kaataa koko projektin. Ajatus täydellisestä uudelleenkirjoittamisesta on houkutteleva, mutta käytännössä se on yleensä itsemurhayritys, joka kestää vuosia ennen kuin käyttäjät näkevät yhtäkään hyötyä.
Tässä kohtaa asteittaisen käyttöönoton taika astuu kuvaan. Sen sijaan, että napsauttaisit kytkintä, alat rakentaa monoliittia pala palalta. Käsittelemällä frontendiäsi itsenäisesti toimitettavien sovellusten kokonaisuutena voit modernisoida teknologiapinoasi ja antaa tiimeillesi mahdollisuuden toimia nopeammin ilman riskialttiiden, big bang -käyttöönottojen stressiä. Kyse on vakauden ja ketteryyden välisen tasapainon löytämisestä.
Fragmenttilävistyksen strategia
Yksi hienoimmista tavoista käsitellä vanhaa siirtymää on tekniikka nimeltä fragment piercing . Kuvittele, että sinulla on hitaasti latautuva React-sovellus. Sen sijaan, että odottaisit koko shellin käynnistymistä, voit renderöidä palvelinpuolen fragmentteja (käyttäen työkaluja, kuten Cloudflare Workers), jotka ovat vuorovaikutteisia lähes välittömästi. Nämä fragmentit sijoitetaan aluksi HTML:n ylimmälle tasolle ja sitten "lävistetään" eli siirretään oikeaan paikkaan DOM:ssa, kun vanha shell lopulta saavuttaa perässä.
Tämä lähestymistapa on pelastus Core Web Vitals -mittareiden parantamisessa , koska se lyhentää vuorovaikutteisuuteen kuluvaa aikaa. Voit esimerkiksi muuttaa kirjautumislomakkeen erilliseksi fragmentiksi. Käyttäjät voivat alkaa kirjoittaa tunnistetietojaan jo ennen kuin pääsovellus on edes olemassa selaimessa. Saumattoman toiminnan takaamiseksi viestiväylää voidaan käyttää kehyksestä riippumattomana tapana, jolla nämä fragmentit voivat kommunikoida vanhan sovelluksen kanssa ilman tiukkaa kytkentää.
Arkkitehtoniset lähestymistavat integrointiin
Tavoitteistasi riippuen on useita tapoja yhdistää nämä palaset. Palvelinpuolen mallien kokoaminen on vanhanaikainen mutta luotettava menetelmä, jossa käytetään esimerkiksi Nginxiä HTML-fragmenttien lisäämiseen. Jos haluat lisää joustavuutta, ajonaikainen integrointi JavaScriptin kautta mahdollistaa säilösovelluksen ladata paketin ja kutsua globaalia renderöintifunktiota. Niille, jotka arvostavat selaimen natiiveja ominaisuuksia, verkkokomponentit tarjoavat standardoidun tavan määrittää mukautettuja elementtejä, jotka komentotulkki voi yksinkertaisesti luoda.
Nykyaikaiset ohjelmistokaupat kallistuvat yhä enemmän moduuliliittoutumiseen . Tämä mahdollistaa sovelluksen ladata moduuleja dynaamisesti toisesta koontiversiosta ajonaikana. Käyttämällä kuluttaja- ja toimittajamallia voit jakaa yksittäisiä komponentteja, kuten React tai Vue, joten käyttäjän ei tarvitse ladata samaa frameworkia viittä kertaa. "Riippuvuushelvetin" välttämiseksi paras tapa on kuitenkin usein käyttää monorepoa , joka varmistaa, että kaikki mikrokäyttöliittymät testataan samoja kirjastoversioita vasten ennen tuotantoon siirtymistä.
Yleisten sudenkuoppien välttäminen
On helppo mennä liiallisuuksiin ja luoda mikrokäyttöliittymäanarkiaa . Yleinen virhe on ajatella, että mikrokäyttöliittymät ovat vain "suuria komponentteja". Painike on komponentti; kassaprosessi on mikrokäyttöliittymä. Jos alat tehdä jokaisesta pienestä käyttöliittymäelementistä erillisen käyttöönotettavan elementin, lisäät vain tarpeetonta toiminnallista monimutkaisuutta . Sinun tulisi aina yhdenmukaistaa rajasi liiketoiminnan aliverkkotunnusten , ei teknisten kerrosten, kanssa.
Toinen ansa on usean kehyksen houkutus . Vaikka voit ajaa Angularia, Reactia ja Svelteä samalla sivulla, se ei tarkoita, että sinun pitäisi. Se tappaa suorituskyvyn ja pirstaloi osaajapooliasi. Ainoa kerta, kun tämä on järkevää, on migraatiostrategian aikana tai yritysoston jälkeen. Jotta sovelluksesi eivät kietoutuisi liikaa yhteen, vältä jaettua globaalia tilaa. Sen sijaan käytä yksisuuntaista tiedonkulkua ja tapahtumapohjaista viestintää pitääksesi tiimit todella itsenäisinä.
Kompromissi: Autonomia vs. yleiskustannukset
Arkkitehtuurissa ei ole ilmaisia lounaita. Valitsemalla mikrokäyttöliittymän vaihdat atomitason versiot itsenäisiin. Tämä tarkoittaa, että saatat kohdata versiovääristymän , jossa sivun eri osissa käytetään jaetun kirjaston eri versioita. Myös kokonaishyötykuorma kasvaa, jos et ole varovainen jaettujen riippuvuuksien kanssa.
Organisaation näkökulmasta tarvitset enemmän CI/CD-prosessia ja parempaa havaittavuutta. Mutta suurelle yritykselle hyöty on valtava: kehittäjien kognitiivinen kuormitus vähenee ja voidaan perustaa uusia tiimejä, jotka voivat omistaa ominaisuuden ideasta tuotantoon. Jos huomaat, että useat mikro-frontendit painiskelevat samaa API-päätepistettä vastaan, se on merkki siitä, että kannattaa arvioida uudelleen rajasi tai ottaa käyttöön Backend-for-Frontend (BFF) näiden kutsujen yhdistämiseksi ja API-laajenemisen estämiseksi.
