- Mikrokäyttöliittymät soveltavat mikropalveluperiaatteita selaimen käyttöliittymään jakamalla suuret käyttöliittymät autonomisiin, toimialuekeskeisiin osioihin, jotka ovat monialaisten tiimien omistamia.
- Integrointi perustuu DOM:iin, mukautettuihin elementteihin, moduuliliittämiseen ja sovelluskuoreen, joka koordinoi reititystä, tietoturvaa, sommittelua ja jaettuja kirjastoja.
- Kehykset, kuten React, Angular ja Next.js, yhdessä mallien, kuten BFF:n, tapahtumaväylien ja laiskan latauksen, kanssa mahdollistavat skaalautuvat, vikasietoiset ja havaittavat mikrofrontend-järjestelmät.
- Mikrokäyttöliittymät lisäävät arkkitehtuuria, mutta ne kannattaa hyödyntää suurissa, usean tiimin tuotteissa, joissa itsenäinen käyttöönotto, asteittainen migraatio ja eriytetty skaalaus ovat ratkaisevan tärkeitä.
Mikrokäyttöliittymät ovat nousseet yhdeksi puhutuimmista käyttöliittymäarkkitehtuurimalleista. tiimeille, jotka ovat kasvaneet ulos klassisesta yhden sivun monoliitista. Kun kymmeniä kehittäjiä työskentelee samassa koodikannassa, julkaisusyklit hidastuvat, regressiot hiipivät kaikkialle ja pienet käyttöliittymämuutokset vaativat yhtäkkiä massiivista koordinointia. Mikrofrontendit ratkaisevat juuri tämän ongelman jakamalla käyttöliittymän itsenäisesti rakennetuiksi ja käyttöönotetuiksi paloiksi.
Tässä oppaassa käymme läpi, mitä mikrofrontendit ovat, miksi ne ilmestyivät ja miten ne liittyvät mikropalveluihin., mitä keskeisiä ideoita sinun tulisi kunnioittaa niitä suunnitellessasi, ja miten ne toimivat käytännössä teknologioiden, kuten Reactin, Angularin, Next.js:n, web-komponenttien, Webpack Module Federationin ja Single-SPA:n, kanssa. Perehdymme myös todellisiin arkkitehtuurimalleihin, hyviin käytäntöihin, yleisiin sudenkuoppiin ja konkreettisiin esimerkkeihin, kuten erillisinä mikrokäyttöliittyminä toteutettuun tuoteluetteloon ja ostoskoriin.
Mitä ovat mikrofrontendit ja miksi ne ilmestyivät?
Termi ”mikrokäyttöliittymät” tuli tunnetuksi noin vuonna 2016 ThoughtWorks Technology Radarissa. vastauksena hyvin konkreettiseen trendiin: taustajärjestelmäarkkitehtuurit siirtyivät mikropalveluihin, mutta selainpuoli pysyi yhden tiimin omistamana suurena, hauraana monoliittina. Ajan myötä tuota "paksua asiakasta" hyödyntävää SPA:ta on vaikea kehittää, vaikka taustajärjestelmä onkin jaettu hienosti pieniin palveluihin.
Mikrokäyttöliittymä on pohjimmiltaan mikropalveluidea, jota sovelletaan selaimen käyttöliittymään.Yhden suuren käyttöliittymätietovaraston sijaan käyttöliittymä kootaan useista pienemmistä, itsenäisistä sovelluksista. Jokaisella on selkeä liiketoiminta-alue (esimerkiksi "kassa", "tuotehaku", "opiskelijaprofiilit"), ja ne voidaan rakentaa, testata ja ottaa käyttöön omalla tahdillaan.
Aivan kuten mikropalvelut jakavat taustajärjestelmän logiikan erillisiin käyttöönotettaviin yksiköihin, mikrofrontendit jakavat käyttöliittymän pystysuoriin osioihin. jotka ulottuvat tietokannasta tai API-rajapinnoista taustajärjestelmän kautta käyttöliittymään. Monialainen tiimi omistaa kyseisen vertikaalisen osan päästä päähän, datakaavasta käyttöliittymäkomponentteihin.
Tämä "vertikaalinen organisaatio" on vastakohta vaakasuoralle kerrosjaolle (yksi tiimi käyttöliittymää varten, toinen API-rajapintoja varten, kolmas tietokantaa varten). Vertikaaliset tiimit toimivat yleensä nopeammin, koska niiden ei tarvitse koordinoida jokaista pientä muutosta yrityksen eri puolilla.
Sovelluksen näkökulmasta mikrofrontend on autonominen verkkosovellus joka voidaan koota laajemmaksi kokemukseksi: sillä voi olla oma reititys, tilanhallinta, suunnittelujärjestelmä ja käyttöönottoputki, kunhan se noudattaa joukkoa sopimuksia muun järjestelmän kanssa (URL-osoitteet, tapahtumat, API:t, jaetut kirjastot jne.).
Mikrofrontendien taustalla olevat ydinajatukset ja periaatteet
Useita toistuvia periaatteita esiintyy onnistuneissa mikrofrontend-arkkitehtuureissa; ne eivät ole tiukkoja sääntöjä, mutta ne säästävät sinut monelta tuskalta, jos käytät niitä kaiteina.
Teknologia-agnostismi on yksi tunnetuimmista periaatteista: jokaisen tiimin tulisi voida valita ja päivittää teknologiapinoaan synkronoimatta sitä kaikkien muiden kanssa. Ehkä yksi mikrofrontend on Reactissa, toinen Angularissa ja vanha Vuessa. Selaimen natiivit abstraktiot, kuten mukautetut elementit (verkkokomponentit), auttavat piilottamaan nämä erot standardin DOM-rajapinnan taakse.
Tiimien koodipohjien vahva eristäminen on toinen keskeinen tavoiteIhannetapauksessa mikrokäyttöliittymät eivät jaa JavaScript-ajonaikaista ympäristöä tai globaaleja muuttujia. Jokainen paketti on itsenäinen, lataa omat riippuvuutensa eikä ole riippuvainen muilta piilotetusta tilasta. Tämä vähentää vahingossa tapahtuvaa kytkeytymistä ja tekee itsenäisistä käyttöönotoista paljon realistisempia.
Välttääkseen nimeämisristiriitoja tiimit sopivat usein eksplisiittisestä nimiavaruudesta. CSS-luokille, DOM-tapahtumille, localStorage-avaimille, evästeille tai jopa mukautettujen elementtien tagien nimille. Esimerkiksi kassatiimi voi lisätä elementteihin etuliitteen chk- tai käytä tunnistetta, kuten <blue-buy>, kun taas suositustiimi käyttää rec- or <green-recos>Yhdellä silmäyksellä DOM kertoo kuka omistaa minkäkin kappaleen.
Toinen periaate on suosia selaimen natiiveja ominaisuuksia mukautettuihin globaaleihin API-rajapintoihin verrattuna.Sen sijaan, että keksit yleiskäyttöisen PubSub-järjestelmän, voit luottaa tavallisiin DOM-tapahtumiin, CustomEvent, historia-API reititystä varten tai itse DOM integraatiokerroksena. Aina kun todella tarvitset jaettua API:a, pidä se mahdollisimman pienenä ja vakaana.
Lopuksi, joustavuuden tulisi olla osa suunnittelua ensimmäisestä päivästä lähtienJokaisen mikrokäyttöliittymän tulisi silti tarjota jonkin verran arvoa, vaikka JavaScript olisi hidas, epäonnistuisi tai estyisi. Tekniikat, kuten palvelinpuolen renderöinti, progressiivinen parannus ja luurankonäytöt, auttavat pitämään havaitun suorituskyvyn korkeana myös huonoissa verkko-olosuhteissa.
Mitä tässä yhteydessä tarkoittaa "moderni verkkosovellus"?
Kaikki verkkosivustot eivät tarvitse mikrokäyttöliittymää tai monimutkaista selainintegraatiostrategiaaHyvä ajatusmalli tulee "dokumenteista sovelluksiin" -jatkumosta: vasemmalla on enimmäkseen staattisia toisiinsa linkitettyjä dokumentteja; oikealla on täysin interaktiivisia sovelluksia, kuten online-kuvankäsittelyohjelma.
Jos projektisi on lähempänä staattisia dokumentteja, yksinkertainen palvelimella renderöity sommittelu riittää usein.Palvelin kerää HTML-fragmentteja eri lähteistä, yhdistää ne ja lähettää ne selaimelle. Päivitykset tapahtuvat koko sivun latauksina tai pieninä Ajax-injektioina, ja se on täysin hyväksyttävää.
Kun siirryt kohti dynaamisempia, sovellusmaisia kokemuksia—välitön palaute, offline-työskentely, optimistiset käyttöliittymäpäivitykset — pelkkä palvelinpuolen integraatio ei enää riitä. Tarvitaan asiakaspuolen kokoonpano, tilanhallinta ja reititys. Tässä kohtaa mikrokäyttöliittymät tulevat mielenkiintoisiksi: ne antavat sinulle keinon skaalata tätä monimutkaisuutta useiden tiimien kesken.
Vertikaalinen organisaatio ja toimialuepohjaiset lohkot
Yleinen suositus on yhdenmukaistaa mikrokäyttöliittymät liiketoiminta-alueiden kanssa teknisten kerrosten sijaan.Ajattele käyttäjäpolkujen näkökulmasta: ”ostoskori”, ”tuotetiedot”, ”ylläpitäjäkäyttäjät”, ”kurssiaikataulut”, ”opiskelijatiedot”, ”laskut” jne.
Jokainen näistä alueista voi toimia omana mikrofrontendinään, jolla on tarkoin määritelty vastuualue.Yliopistojärjestelmässä yksi sovellus voisi hallita opiskelijaprofiileja, toinen henkilökunnan profiileja, kolmas kurssien aikatauluja ja kolmas koetuloksia. Niillä on yhteinen käyttöliittymä ja ehkä jonkin verran tyyliä, mutta jokainen on itsenäinen sovellus käyttöönoton näkökulmasta.
Hyvä viipalointi ottaa huomioon myös taustapalveluidesi rajatut kontekstitIhannetapauksessa ”laskutuksen” mikrokäyttöliittymä on yhteydessä pääasiassa laskutusmikropalveluihin, ”luettelon” käyttöliittymä on yhteydessä luettelointipalveluihin ja niin edelleen. Tämä pitää jokaisen vertikaalisen osan yhtenäisenä ja vähentää tiimien välisiä riippuvuuksia.
Tekninen integraatio: DOM API:na ja verkkokomponentteina
Selainpuolen mikrokäyttöliittymäarkkitehtuureissa DOM itse toimii usein ensisijaisena integraatio-API:na.Sen sijaan, että tiimit kutsuisivat toistensa JavaScriptiä suoraan, he paljastavat toiminnallisuuden HTML-elementtien, attribuuttien ja tapahtumien kautta.
Mukautetut elementit (osa verkkokomponentteja) ovat tehokas primitiivi tähän tarkoitukseen.Tiimi voi rakentaa ominaisuuden käyttämällä haluamaansa kehystä ja sitten kääriä sen mukautetuksi tagiksi, esimerkiksi <order-minicart></order-minicart>Kyseisen komponentin julkinen sopimus määritellään sen tagin nimellä, attribuuteilla ja emittoiduilla tapahtumilla, ei sen sisäisellä toteutuksella.
Selaintuki Custom Elements v1:lle on nyt vakaa kaikissa tärkeimmissä selaimissa, mikä tarkoittaa, että polyfillien käyttöä tarvitaan harvoin. Useimmat valtavirran kehykset – React, Vue, Angular, Svelte, Preact – voivat renderöidä tai upottaa mukautettuja elementtejä ikään kuin ne olisivat tavallisia HTML-tageja, ja monet niistä voidaan myös kääntää itse mukautetuksi elementiksi.
Integraatiomalli näyttää suunnilleen tältä”Tuotesivun” mikrokäyttöliittymä päättää, mitkä ominaisuudet näkyvät sivulla (valitsimet, ostopainikkeet, miniostoskori, suositukset). Se lisää mukautettuja elementtejä, kuten <blue-buy sku="t_porsche"></blue-buy> or <green-recos sku="t_porsche"></green-recos>Kyseiset ominaisuudet omistavat joukkueet rekisteröivät elementtinsä customElements.define ja toteuttaa elinkaarikutsuja, kuten connectedCallback or attributeChangedCallback.
Kun tuotevariantti muuttuu, sivu voi joko luoda elementin uudelleen tai vain päivittää sen määritteet.Jos komponentti havaitsee asiaankuuluvia attribuutteja, se voi renderöidä itsensä uudelleen. Sisäisesti komponentti voi käyttää mallinemerkkijonoja, Reactia, Vueta tai mitä tahansa renderöintimoottoria; integraattorin ei tarvitse välittää tästä.
Asiakaspuolen viestintä: tapahtumat ja DOM-suhteet
Määritteiden välittäminen toimii hyvin yksisuuntaisissa "datan sisään" -tilanteissa., mutta monet todelliset vuorovaikutustilanteet vaativat komponentteja kommunikoimaan takaisin ympäristölleen tai sisaruksilleen. Tyypillinen esimerkki on "osta"-painike, jonka on ilmoitettava minikoriin, kun tuote lisätään.
Sen sijaan, että rakentaisit mukautetun globaalin tapahtumaväylän, voit nojata selaintapahtumiinKomponenttien lähetys CustomEvent esiintymät, jotka kuplivat ylös DOM-puun läpi. Yläelementti tai jopa window voi kuunnella näitä tapahtumia ja suunnitella vastauksia.
Esimerkiksi ostopainike voi käynnistää tapahtuman, kuten blue:basket:changed nykyisellä ostoskorin hyötykuormallaMinikärry tilaa kyseisen tapahtuman osoitteessa window tai jaetussa säilöelementissä ja päivittää sisäisen tilansa aina, kun se käynnistyy.
Tämä lähestymistapa pitää komponentit itsenäisinäOstopainikkeella ei ole aavistustakaan, kuka, jos kukaan, kuuntelee sen tapahtumia. Se vain täyttää sopimuksensa. Ja mini-ostoskori on riippuvainen vain tapahtumien semantiikasta, ei muiden fragmenttien toteutusyksityiskohdista.
Palvelinpuolen renderöinti ja universaalit komponentit
Jos välität ensisilmäyksellä suoritettavasta suorituskyvystä, hakukoneoptimoinnista tai JavaScriptin epäonnistuessa ilmenevästä vikasietoisuudesta, palvelinpuolen renderöinnistä (SSR) on kyse.Puhtaasti asiakaspuolen verkkokomponentit näkyvät vasta JS-paketin latauksen ja suorittamisen jälkeen, mikä voi tarkoittaa valkoista näyttöä hitaissa verkoissa.
Käytännöllinen ratkaisu on yhdistää mukautetut elementit palvelinpuolen include-toimintoihin (SSI/ESI)Jokainen mikrokäyttöliittymä paljastaa HTTP-päätepisteen, joka palauttaa HTML-koodin sen fragmentille, esimerkiksi /blue-buy?sku=t_porschePääsivu, jonka hahmontaa komentotulkki tai isäntäsovellus, sisältää paikkamerkkejä, kuten <!--#include virtual="/blue-buy?sku=t_porsche" --> jonka web-palvelin (usein nginx) laajentaa ennen vastauksen lähettämistä selaimelle.
Selaimen suorituksen aikana sama mukautettu elementti hydratoidaan tai alustetaan uudelleen. kun sen JS-paketti latautuu. Se antaa sinulle "universaalin" komponentin: se voi renderöidä palvelimella nopeuden ja hakukoneoptimoinnin parantamiseksi ja toimia sitten täysin interaktiivisena mukautettuna elementtinä asiakasohjelmassa.
Yksi SSR:n haittapuoli, jossa on sisällytyksiä, on se, että hitain fragmentti sanelee kokonaisvasteajan.Fragmenttitason välimuistiin tallennus on lähes pakollista. Kalliiden ja erittäin personoitujen osien (kuten suositusten) kohdalla voit ohittaa palvelinpuolen renderöinnin ja ladata ne asynkronisesti asiakasohjelmaan.
Luurankonäytöt ovat hyvä kompromissi häiritsevien asettelumuutosten välttämiseksiFragmentti voi palvelimen puoleen renderöidä harmaana näkyvän paikkamerkin, jonka koko on suunnilleen sama kuin lopullisen sisällön. Kun varsinainen data saapuu asiakaspuolelle, runko vaihdetaan ilman suuria uudelleenjuoksutuksia.
Tiedon lataus ja koettu suorituskyky
Mikrokäyttöisessä maailmassa on mietittävä tarkkaan, mistä ja milloin dataa noudetaan.Voit hakea kaiken palvelinpuolen, asiakaspuolen tai käyttää hybridiä. Jokainen valinta vaikuttaa välimuististrategioihin, vuorovaikutteisuuteen kuluvaan aikaan ja havaittuun nopeuteen.
Palvelinpuolen sisällytykset luonnollisesti kannustavat palvelinpuolen hakuihin fragmenttikohtaisestiJokainen mikrokäyttöliittymä on yhteydessä "omiin" taustapalveluihinsa, renderöi HTML-koodin ja palauttaa sen komentotulkille. Tämä HTML-koodi voidaan tallentaa välimuistiin muista fragmenteista riippumatta, mikä auttaa skaalaamaan paljon liikennöityjä osia, kuten kirjautumista tai tuotelistoja.
Kun lataat dataa asiakkaalle, sinun tulee budjetoida progressiiviset tilat: alkuperäinen runko, nopeat päivitykset ominaisuuksien muuttuessa ja varatoiminto, kun API:t ovat hitaita. Joskus vanhan datan pitäminen paikallaan, kunnes uusi data saapuu, on visuaalisesti vähemmän häiritsevää kuin rungon päivittäminen jokaisesta pienestä muutoksesta.
Mikrokäyttöliittymät Reactin avulla
React on erittäin suosittu valinta mikrofrontendien toteuttamiseen ekosysteeminsä ja renderöintioptimointiensa ansiosta.Virtuaalinen DOM ja vertailut tekevät käyttöliittymän pienten osien päivittämisestä helppoa prop-muutosten tai globaalin tilan perusteella, ja voit niputtaa React-sovelluksia joko erillisiksi SPA-elementeiksi tai mukautetuiksi elementeiksi.
React-versioiden välinen siirtyminen on yleensä inkrementaalista ja suhteellisen kivutonta verrattuna joihinkin muihin frameworkeihin, mikä on hyödyllistä, kun useat itsenäiset tiimit ylläpitävät erillisiä mikrokäyttöliittymiä. Kaikkien fragmenttien ei tarvitse hypätä pääversiosta toiseen samanaikaisesti.
Kääntöpuolena on, että hajautetut React-mikrokäyttöliittymät voivat aiheuttaa resurssien hajaannusta.useita tiimejä, useita CI/CD-putkia, useita paketteja, useita pieniä repositorioita. Ilman riittävää automaatiota koonnille, tarjoamiselle ja havainnoinnille tästä ylimääräisestä työstä tulee vaikea hallita.
Toinen käytännön kysymys on nipun kokoJos jokainen mikrokäyttöliittymä toimittaa oman kopionsa Reactista ja jaetuista kirjastoista, latausten kokonaiskoko voi räjähtää, varsinkin kun sivun renderöintiin tarvitaan useita fragmentteja. Ratkaisut, kuten moduulien federaatio (riippuvuuksien jakamiseksi ajonaikana) tai vahvasti linjattu pino tiimien välillä, voivat lieventää tätä.
Mikrokäyttöliittymät Angularin avulla
Angular sopii hyvin mielipiteitä vaativampiin mikrokäyttöliittymäympäristöihin, erityisesti silloin, kun käytät monorepoja ja niiden ympärillä olevia työkaluja (kuten Nx). Angular-työtilat on järjestetty projekteiksi ja kirjastoiksi, minkä ansiosta on luonnollista jakaa suuri ratkaisu useisiin sovelluksiin ja jaettuihin kirjastoihin.
Angular 12:n ja Webpack 5:n jälkeen Module Federationista on tullut ensiluokkainen kansalainenAngular-projekti voidaan konfiguroida isännäksi tai etätyöasemaksi kytkentäkaaviokomennoilla, kytkemällä tarvittavat webpack.config.js ja bootstrap-logiikkaa sinulle.
Tässä mallissa "isäntä" Angular-sovellus toimii komentotulkkina joka koordinoi navigointia, jaettua tilaa ja riippuvuuksien jakamista. Yksittäiset Angular-mikrokäyttöliittymät (etäkäyttöliittymät) paljastavat Angular-moduuleja, jotka isäntä voi ladata laiskasti dynaamisesti moduuliliiton kautta.
Tavalliset kulmareitityksen primitiivit ovat edelleen voimassaMikrokäyttöliittymän sisällä käytät RouterModule.forChild lapsireittimääritelmille, jotta isäntä on ainoa, joka käyttää forRootTällä tavoin useita Angular-sovelluksia voi esiintyä rinnakkain yhtenäisen URL-avaruuden alla ilman reititinkonflikteja.
Moduulien federointi käytännössä (Angular-esimerkki)
Webpack Module Federation on Webpack 5:n ominaisuus, jonka avulla useat koontiversiot voivat jakaa koodia ajonaikana.Yksi koontiversio (isäntäversio) lataa dynaamisesti muiden koontiversioiden (etäversioiden) paljastamia moduuleja pienen manifest-tiedoston kautta, jonka nimi on tyypillisesti remoteEntry.js.
Angularissa voit tehdä tämän telineillä melko nopeasti.Voit esimerkiksi luoda isäntäsovelluksen (host-app) ja suorita sitten kytkentäkaavio, kuten ng add @angular-architects/module-federation --project host-app --port 4200Tämä määrittää ModuleFederationPlugin-kokoonpanon, käynnistystiedostot ja ajonaikaisen logiikan.
Sitten luot kaksi Angular-etäsovellusta: yhden tuoteluetteloa ja toisen ostoskoria varten.Jokainen sovellus saa oman portin (esim. 4201 sovellukselle products-app, 4202 varten cart-app) ja oma moduuliliittoutumiskonfiguraationsa. webpack.config.js jokaisesta käyttämästäsi kaukosäätimestä exposes julkaista moduuli (yleensä pääsovellusmoduuli) avaimella, kuten ./ProductsModule or ./CartModule.
Isäntäkuori määrittää sitten reitit, jotka lataavat kyseiset etämoduulit laiskasti. kautta loadRemoteModule alkaen @angular-architects/module-federationEsimerkiksi navigointi kohteeseen /products käynnistää dynaamisen tuonnin kohteesta http://localhost:4201/remoteEntry.js ja kuormia ProductsModule; /cart tekee saman kärryn kaukosäätimen kanssa.
Katalogian mikrokäyttöliittymän sisällä saattaa olla ProductsComponent joka renderöi kohteiden taulukon, lukee tietoja PRODUCTS_CATALOG vakiona ja tarjoaa Lisää ostoskoriin -painikkeen. Klikkaamalla se pitää tuotteen ostoskoriin. localStorage ”ostoskori”-näppäimellä, jolloin määriä kasvatetaan, kun tuote on jo olemassa.
Ostoskorin mikrokäyttöliittymä lukee sitten samasta localStorage avain, näyttää taulukon, jossa on tuotteen nimi, hinta, määrä ja kokonaissumma, ja tarjoaa ”Tyhjennä ostoskori” -painikkeen, joka tyhjentää tallennustilan ja nollaa sen sisäisen tilan. Tämä on yksinkertainen mutta havainnollistava tapa jakaa tila kahden itsenäisen sovelluksen välillä ilman tiukkaa kytkentää.
Isäntäkuoren rakentaminen: ulkoasu, aloitussivu ja navigointi
Vahva isäntäkuori on kriittinen hyvän käyttökokemuksen kannalta mikrokäyttöliittymässä.Se omistaa yleensä globaalin asettelun (ylätunnisteen, alatunnisteen, sivupalkit), ylimmän tason reitityksen ja joskus globaalit tilatiedot, kuten todennuksen tai ominaisuusliput.
Angular-esimerkissä isäntä määrittelee LayoutComponent joka renderöi otsikon ja sisäkkäisen router-outletYlätunniste on omassa osiossaan. HeaderModule ja näyttää navigointilinkit kotisivulle, tuotelistaukseen ja ostoskoriin Angularin kautta routerLinkReittipolut voidaan keskittää enumiin, kuten RoutesPath välttääkseen taikasankoja.
Reititysmoduuli asettaa pääreitin, jossa on LayoutComponent sen osana ja määrittelee lapsireitit /home, /products ja /cart. /home polku lataa paikallisen HomeModule; muut käyttävät loadRemoteModule hakeakseen Angular-mikrokäyttöliittymät suorituksen aikana.
Isännän sisällä a SharedModule voi kerätä uudelleenkäytettäviä rakennuspalikoita kuten otsikko, asettelu, yleiset direktiivit ja vakiot. Tämä moduuli voidaan tuoda juureen AppModule yhdessä AppRoutingModule, joka osoittaa tyhjän polun asettelun reitityskokoonpanoon.
Next.js ja mikrokäyttöliittymät
Next.js, tuotantotason React-kehyksenä, toimii hyvin myös mikrofrontend-lähestymistavan kanssa., varsinkin kun se otti käyttöön Webpack 5:n ja siten Module Federation -tuen. Sen keskittyminen SSR:ään, inkrementaaliseen staattiseen regenerointiin ja reititykseen tekee siitä hyvän ehdokkaan käyttöliittymälle, yksittäisille mikrokäyttöliittymärajapinnoille tai molemmille.
Mikrofrontendin toteuttamiseksi Next.js:ssä konfiguroidaan tyypillisesti Module Federation Webpack-tasolla., paljastaen tietyt sivut tai komponentit etänä ja kuluttaen niitä isännästä. Vaikka Module Federation on "vain" JavaScriptin niputtajaominaisuus, voit ajatella sitä arkkitehtonisena mallina: sen avulla voit ladata eri tiimien omistamaa koodia dynaamisesti ilman, että kaikkea tarvitsee niputtaa yhteen etukäteen.
Vanhoille Next.js-versioille ilman Webpack 5:tä tarvitsisit ulkoisia sovittimia. ottaa käyttöön federaatiotuen. Next 10.2:sta eteenpäin Webpack 5 -tuki on sisäänrakennettu, mikä yksinkertaistaa asennusta huomattavasti.
Single-SPA ja muut mikrokäyttöliittymäkehykset
Single-SPA on toinen tunnettu ratkaisu mikrofrontendeille, erityisesti React-ekosysteemeissä.Se keskittyy useiden itsenäisten sovellusten organisointiin samalla sivulla, joista jokainen on liitetty omaan DOM-solmuunsa nykyisen reitin perusteella.
Single-SPA:n avulla voit käyttää useita React-sovelluksia (tai jopa sekoittaa Reactia, Vueta ja Angularia) rinnakkainKehys käsittelee kunkin mikrokäyttöliittymän käynnistys-, liittämis- tai irrotusajan käyttäjän navigoidessa, ja sinä kytket sen reititysstrategiaasi (esimerkiksi React Routerin avulla jokaisessa fragmentissa).
Kun valitset yhden SPA:n ja moduuliliiton välillätiimit ottavat usein huomioon pakettien/työkalujen mieltymykset. Moduulien federaatio integroituu syvästi Webpackin kanssa (ja yhä useammin vaihtoehtojen, kuten Rspackin tai Rollupin, kanssa, kun ne lisäävät tukea). Toisaalta Single-SPA keskittyy enemmän ajonaikaiseen orkestrointiin kuin pakettien jakamiseen, joten sitä voidaan käyttää eri käännöstyökalujen kanssa samalla, kun koodin jakamista käsitellään muilla tavoilla.
Mikrofront-endien tavoitteet, ominaisuudet ja hyödyt
Mikrofront-end-kehityksen päätavoitteena on skaalata front-end-kehitystä useiden tiimien kesken ilman, että se romahtaa koordinointikustannusten alle.Yhden jättimäisen koodikannan ja synkronoitujen julkaisujen sijaan saat pienempiä, itsenäisesti käyttöönotettavia yksiköitä.
Keskeisiin tavoitteisiin kuuluvat yleensä mahdollistamalla useiden tiimien rinnakkaisen työskentelyn, tukemalla käyttöliittymän eri osien itsenäistä käyttöönottoa, säilyttämällä joustavuuden käyttää eri teknologioita siellä, missä se on järkevää, ja parantamalla ylläpidettävyyttä pienentämällä kunkin koodikannan kokoa ja monimutkaisuutta.
Tällaisen arkkitehtuurin tyypillisiä ominaisuuksia ovat komponenttien uudelleenkäyttö jaettujen kirjastojen kautta, modulaarinen integrointi sovelluskuoren kautta, itsenäiset putket mikrokäyttöliittymää kohden, suorituskyvyn optimointi CDN-verkkojen ja välimuistin avulla, keskitetty tietoturvan käsittely ja vahva havainnoitavuus.
Liiketoiminnan näkökulmasta hyödyt ovat huomattavatkehitys skaalautuu paremmin useamman tiimin kanssa, virheet eristetään paremmin, ominaisuuksia voidaan ottaa käyttöön tai palauttaa toimialueittain, ja vanhat käyttöliittymäpinot voidaan siirtää vähitellen korvaamalla yksi osa kerrallaan sen sijaan, että koko sovellus kirjoitettaisiin uudelleen.
Mikrofrontend-arkkitehtuurin keskeiset komponentit
Vaikka toteutukset vaihtelevat, useimmilla mikrokäyttöliittymäarkkitehtuureilla on muutamia yhteisiä rakenteellisia komponentteja. jotka pitävät kaiken johdonmukaisena.
Sovelluskuori (tai säilö) on selkärankaSe omistaa ulkoisen asettelun, globaalin navigoinnin, todennuksen, joskus globaalin tilan ja mikrokäyttöliittymien lataamisen ja purkamisen logiikan. Selainpohjaisissa kokoonpanoissa sivu noutaa kaikki muut paketit.
Jokainen mikrokäyttöliittymä on itsenäinen moduuli, joka toteuttaa tietyn ominaisuuden, kuten tuoteluettelo, ostoskori, käyttäjäprofiili tai hallintapaneeli. Se näyttää integraatiopinnan (reitit, mukautetut elementit, moduuliliitosten etäkäyttöoikeudet) ja piilottaa sisäiset tiedot muulta järjestelmältä.
Mikrokäyttöliittymän välistä viestintää varten on usein käytössä tapahtumaväylä tai viestijärjestelmä.Tämä voi olla yksinkertainen DOM-tapahtumien abstraktio, keskitetty Redux-säilö tai mukautettu viestivälityspalvelu. Tavoitteena on erillinen julkaisu-/tilaussemantiikka: mikrokäyttöliittymä lähettää tapahtumia tietämättä, kuka niitä käsittelee.
Jaetut kirjastot isännöivät uudelleenkäytettäviä käyttöliittymäkomponentteja, apuohjelmia, suunnittelutokeneita ja yleisiä asiakasohjelmiaMonoarkiston asetuksissa työkalut, kuten Nx, loistavat tässä, sillä niiden avulla voit määrittää useiden sovellusten käyttämiä jaettuja paketteja pakotetuilla rajoilla ja yhdenmukaisilla versioilla.
Havaittavuuskerääjät ja -työkalut (esimerkiksi OpenTelemetryn avulla) koota lokit, mittarit ja jäljet kaikista mikrokäyttöliittymärajapinnoista, mikä mahdollistaa useiden fragmenttien tai palveluiden laajuisten ongelmien diagnosoinnin.
CDN:t täydentävät kuvan toimituspuolella, tallentamalla staattisia resursseja, kuten JS-paketteja, CSS:ää ja kuvia, lähelle käyttäjiä, mikä vähentää viivettä ja keventää alkuperäispalvelimien kuormitusta. Mikrokäyttöisissä kokoonpanoissa usein isännöidään jokaisen fragmentin resursseja omalla CDN-polullaan itsenäistä välimuistitallennusta ja käyttöönottoa varten.
Mikrokäyttöliittymän arkkitehtuuri ja suunnittelumallit
Mikrofrontendeihin soveltuvia malleja on runsaasti., yleensä määriteltynä sillä, miten ne kootaan, otetaan käyttöön ja yhdistetään.
Komponenttipohjainen sommittelu tarkoittaa käyttöliittymän rakentamista verkkokomponenteista tai vastaavista peruselementeistä.Jokaisella komponentilla on yksi vastuualue, selkeät syötteet ja tuotokset, ja niitä voidaan testata erikseen. Ylemmän tason sommittelukerros (kuten komentotulkki tai orkestrointikehys) järjestää nämä komponentit kokonaisiksi sivuiksi.
Liittomalli korostaa sovelluksen täydellistä autonomiaaJokainen mikrokäyttöliittymä on itsenäinen sovellus, jolla on oma elinkaari ja tiimi; komentotulkki tai API-yhdyskäytävä yksinkertaisesti reitittää pyynnöt/datan oikeaan fragmenttiin. Viestintä tapahtuu hyvin määriteltyjen REST-rajapintojen tai -tapahtumien kautta.
Sovelluskuorimalli on käytännössä "isäntä"-lähestymistapaKomentotulkki lataa mikrokäyttöliittymät, käsittelee monialaisia ongelmia, kuten navigoinnin ja tietoturvan, ja varmistaa yhtenäisen ulkoasun ja käyttökokemuksen. Tämä on hyvin yleistä moduuliliittymis- tai yksittäisten SPA-pohjaisten kokoonpanojen kanssa.
API-yhdyskäytävän ja Backend-for-Frontend (BFF) -mallit keskittyvät palvelinpuoleenAPI-yhdyskäytävä sijaitsee useiden taustapalveluiden edessä reitittäen pyyntöjä ja soveltaen tietoturvaa. BFF menee pidemmälle: jokainen käyttöliittymä (verkko, mobiili, IoT) voi saada oman erillisen taustajärjestelmän, joka on räätälöity sen tarpeisiin.
Hajautetut tiedontallennusmallit ottavat huomioon, että eri mikrokäyttöliittymät saattavat hallita omia tietolähteitään tai välimuisteja. Selaimessa tämä tarkoittaa usein erillisten localStorage-avainten, IndexedDB-tietokantojen tai muistissa olevien tallennustilojen käyttöä, kun taas taustalla se tarkoittaa erillisiä tietokantoja mikropalvelua kohden.
Havaittavuus, itsenäinen käyttöönotto, horisontaalinen skaalautuvuus ja tietoturvamallit käsitellä operatiivisia kysymyksiä: miten kutakin fragmenttia valvotaan, miten ne otetaan käyttöön ilman globaaleja käyttökatkoksia, miten niitä skaalataan kuormituksen aikana ja miten todennus/valtuutus varmistetaan johdonmukaisesti.
Reitityksen koostumus ja laiskat latausmallit ovat keskeisiä käyttökokemuksen ja suorituskyvyn kannalta.Pääreititin päättää, mikä mikrofrontend käsittelee mitäkin polkua, ja jokaisella mikrofrontendilla on oma sisäinen reitittimensä. Laiska lataus varmistaa, että lataat vain ne koodifragmentit, joita nykyinen reitti todella tarvitsee.
Lopuksi, tapahtumapohjaiset kommunikaatiomallit varmistavat, että löyhästi kytketyt mikrofrontendit voivat edelleen koordinoida verkkotunnustapahtumien kautta ilman, että luodaan suoria riippuvuuksia, jotka kumoaisivat modulaarisuuden periaatteen.
Milloin käyttää mikrofrontendiä (ja milloin ei)
Mikrokäyttöliittymät loistavat suurissa ja monimutkaisissa sovelluksissa, joilla on tarkoin määritellyt toiminnalliset alueetAjattele esimerkiksi verkkokauppa-alustoja, yrityksen hallintajärjestelmiä, kuntaportaaleja, koulutusalustoja, suuria terveysportaaleja tai mitä tahansa tuotetta, jossa on useita tiimejä, jotka työskentelevät erillisillä toiminnallisilla alueilla.
Ne ovat erityisen hyödyllisiä, kun useita tiimejä työskentelee rinnakkain. jotka tarvitsevat itsenäisyyttä teknisissä valinnoissa, julkaisusykleissä ja prioriteeteissa, tai kun modernisoit hitaasti vanhaa käyttöliittymää etkä pysty kirjoittamaan sitä kokonaan uudelleen. Voit luoda uuden mikrokäyttöliittymän yhdeksi alueeksi kerrallaan ja integroida sen vanhaan shelliin.
Ne auttavat myös silloin, kun sovelluksen eri osia on skaalattava eri tavalla.Kirjautumis- tai kassasivu saattaa saada paljon enemmän liikennettä kuin järjestelmänvalvojan määritysnäyttö; näiden osien skaalaaminen erikseen voi säästää paljon infrastruktuurikustannuksia.
Mikrofrontendit eivät kuitenkaan ole ilmainen lounas.Ne lisäävät arkkitehtuuria, vaativat vahvaa koordinointia käyttökokemuksessa ja jaetuissa sopimuksissa ja tuovat mukanaan uusia vikatiloja (esimerkiksi yhden fragmentin latautuminen). Pienille tai keskisuurille sovelluksille, joissa on yksi tiimi, hyvin jäsennelty monoliitti on usein yksinkertaisempi ja kustannustehokkaampi.
Tiimien tulisi myös olla varovaisia "kehysanarkian" suhteen.Vaikka on teknisesti mahdollista, että jokainen mikrofrontend käyttää täysin eri koodipinoa, hallitsematon useiden eri kehysten yhdistelmä vaikeuttaa rekrytointia, työkalujen käyttöä ja koodin jakamista. Kohtuullinen yhdenmukaisuus (esimerkiksi "olemme React-first-kauppa, mutta sallimme Angularin tietyillä verkkotunnuksilla") toimii yleensä paremmin pitkällä aikavälillä.
Mikrokäyttöliittymät laajentavat mikropalveluajattelua selaimeen antaen tiimeille keinon jakaa suuria käyttöliittymiä itsenäisiksi, toimialuekeskeisiksi paloiksi, jotka voivat kehittyä, ottaa käyttöön ja skaalautua itsenäisesti, mutta jotka muodostavat silti yhtenäisen käyttökokemuksen yhdistettynä sovelluskuoren, jaettujen kirjastojen, moduuliliiton, verkkokomponenttien tai orkestrointikehysten, kuten Single-SPA:n, avulla.
