Kazalo[Skrij][Pokaži]
Zamisel o mikrostoritvah je v zadnjem času pridobila veliko pozornosti in mnoga podjetja jo uporabljajo za odpravo velikih, monolitnih ozadij.
Iti po isti poti s sprednjim delom je še vedno izziv za številna podjetja, čeprav je ta porazdeljeni način konstruiranja strežniške strani spletnih aplikacij bolj ali manj zanesljiv v smislu raziskav in izvajanja.
Zaradi tesne odvisnosti monolit na strani odjemalca običajno otežuje integracijo novih funkcij, sprejemanje novih tehnologij in prilagajanje posameznih komponent.
Ti in drugi izzivi so spodbudili razvijalce frontend, da raziščejo uporabo mikrostoritev.
Posledično je bila razvita popolnoma nova arhitekturna strategija, znana kot mikro frontend, za ustvarjanje sprednjega sloja spletnih mest in spletnih aplikacij.
Izraz je bil prvič uporabljen leta 2016 in od takrat je požel veliko pozornosti za dober namen.
Ta članek bo podal splošno razumevanje, kaj so mikro vmesniki in težave, ki jih obravnavajo. deluje, pa tudi prednosti in slabosti.
Uvod v mikro front-end arhitekturo
Sodobna metoda front-end razvoja, imenovana mikro-frontend arhitektura, deli a spletne aplikacije na majhne, samostojne dele.
Končnemu uporabniku se zdi, da so ti deli ena enota, tudi če so bili izdelani neodvisno in nato sestavljeni.
Z razliko, da se mikro vmesniki nanašajo na odjemalsko, ne na strežniško stran spletnih rešitev, je njihova osnova enaka kot pri mikrostoritvah.
Izdelava sofisticiranih spletnih izdelkov je najbolj smiselna pri uporabi mikro frontend pristopa.
Mikro vmesniki, v nasprotju z bolj običajnim monolitom sprednjega dela, omogočajo številnim ekipam, da ločeno sodelujejo pri različnih projektih programske opreme.
Programerji lahko s to arhitekturno zasnovo ustvarijo spletne aplikacije hitreje in z večjo razširljivostjo ter vzdržljivostjo.
Preprosto povedano, vsak mikro frontend je le delček kode za ločeno komponento spletne strani.
Te funkcije nadzorujejo ločene ekipe, od katerih je vsaka specializirana za določeno panogo ali cilj.
Monolitna vs Microservices vs Micro frontend arhitektura
Pomislite na selitev. Ali vam bo preprosteje organizirati vse v več majhnih, strokovno označenih škatel in prestaviti vsako posebej ali pa celotno osebje zapakirati v eno ogromno škatlo in jo prepeljati na novo lokacijo?
Očitna rešitev je tam.
Ta analogija primerja dve različni arhitekturi spletnih aplikacij, monolite in mikrostoritve (znane tudi kot mikro vmesniki).
Monolitna arhitektura
Morda se boste lahko spomnili »dobrih starih časov«, ko je bila popolna aplikacija ustvarjena kot ena sama kohezivna entiteta. Tak način imenujemo monolit, kar je star izraz za velik kamniti blok.
To je smiselno.
Monolitni sistemi imajo medsebojno odvisne elemente. Če torej želite nekaj spremeniti ali dodati novo funkcijo, je možno, da se celoten sistem pokvari.
Čeprav je zastarel, občasno še vedno obstaja. Da, zavedamo se vašega trenutnega izraza.
Konceptualna delitev kodne baze na dve različni komponenti — frontend (na strani odjemalca) in backend (na strani strežnika) — je postala neizogibna, ko so se razvile nove tehnologije in so programski izdelki postali bolj zapleteni.
Najbolj priljubljen način delovanja je zdaj ločevanje zadev med predstavitveno plastjo, s katero komunicira končni uporabnik, in vsem, kar se dogaja v ozadju.
Potrebuje dve ekipi programskega inženiringa, s sprednjo ekipo, ki gradi vizualne komponente, in zadnjo skupino, ki gradi spletne storitve, poslovno logiko, dostop do podatkov, integracije itd.
Kljub tej ločitvi pa ta strategija po naravi še vedno ostaja monolitna.
Glavna sprememba je, da imamo zdaj dva precejšnja bloka kode – frontend in backend – namesto ene ogromne aplikacije. Ni nujno, da so monolitne arhitekture grozne; imajo nekaj prednosti, med drugim
- Enostaven in hiter razvoj za majhne aplikacije z eno izvorno kodo in zelo preprostim dizajnom;
- Preizkušanje in odpravljanje napak sta zelo preprosta, ker je vsa koda na enem mestu, kar ekipi olajša sledenje toku zahteve in odkrivanje napak;
- Na začetku razvoja aplikacije so stroški nižji, saj ne nastanejo niti stroški infrastrukture niti stroški razvoja, dokler niso dodane nove funkcije.
Slabosti te strategije se odražajo v
- Omejena prilagodljivost uvajanja – ekipe morajo počakati, če jih na projektu dela le peščica, in nova uvedba je potrebna vsakič, ko posodobite kodo;
- Sprejemanje novih tehnologij je izziv, saj je za to treba prepisati pomemben del, če ne celoten projekt.
- Ko se število razvijalcev poveča, postane sistem kode tesno povezan, zapleten ter težko obvladljiv in razumljiv.
- Organizacijska vprašanja – vsak član ekipe mora uporabljati isto različico knjižnic in poročati o morebitnih spremembah, če več skupin dela na monolitnem projektu.
- Pomisleki glede razširljivosti – ker so komponente projekta med seboj povezane, njihovo ločeno prilagajanje predstavlja težave, ki povzročijo znatne izpade in višje izdatke.
- Zapleteno logiko projekta bi lahko novi člani ekipe težko razumeli, zlasti če inženirji, ki so prvotno delali na njem, niso več zaposleni.
Razvoj mikrostoritev in njihovih bližnjih sorodnikov ter mikro vmesnikov je obravnaval primarne težave z monolitnimi sistemi.
Arhitektura mikrostoritev
Arhitekturna metoda, znana kot mikrostoritve, omogoča ustvarjanje številnih ohlapno povezanih in neodvisno razporeljivih manjših komponent ali storitev, ki sestavljajo zaledje aplikacije.
Vsaka storitev ima lastno kodno zbirko, cevovode CI/CD, postopke DevOps in procese za njihovo izvajanje.
Če pogledate zgornjo sliko, lahko vidite, da je monolitna zaledna ekipa razdeljena na ločene ekipe.
Vsak se posebej osredotoča na drugačen vidik aplikacije (kot je storitev izdelka, iskalna storitev in plačilna storitev).
Komunikacija med storitvami poteka prek uveljavljenih protokolov, znanih kot API-ji, kot je lahki protokol REST API, ki uporablja sinhrone vzorce zahtev-odgovorov.
Druga možnost je uporaba asinhrone komunikacije z uporabo programske opreme, kot je Kafka, ki ponuja komunikacijske strukture in dogodke objave/naročnine.
Mikrostoritve se integrirajo s sprednjim delom prek zaledja za storitev sprednjega dela (BFF) ali prehoda API prek omrežja. BFF ponuja prilagojen API za vsakega odjemalca, medtem ko API prehodi ponujajo eno samo dostopno točko za zbirko mikrostoritev.
Toda tudi z avtonomnimi zalednimi komponentami in vsemi prednostmi, ki jih ponujajo, je sprednji del še vedno monolit.
Zato so tukaj uporabne mikro vtičnice.
Arhitektura mikro vmesnikov
Podobno kot pri mikrostoritvah, kjer ohlapno povezane komponente upravlja več skupin, mikro frontend arhitektura uporablja koncept za brskalnik.
Ti uporabniški vmesniki spletnih aplikacij sledijo tej strukturi, ki je sestavljena iz nekoliko avtonomnih komponent.
Ekipe so ustvarjene tudi na podlagi potreb strank ali primerov uporabe, ne pa glede na posebno strokovno znanje ali tehnologijo.
Posledično so ekipe vključene v mikrostoritve in mikro frontend projekte.
- navpično razrezano – ker na istem projektu delajo tudi razvijalci čelnega vmesnika, strokovnjaki za podatke, inženirji zaledja, inženirji za zagotavljanje kakovosti itd., ustvarjajo svoje funkcije iz Uporabniški vmesnik v baze podatkov; in
- medfunkcionalno – vsak član skupine prispeva svoje strokovno znanje in izkušnje skupini.
Ekipe lahko tudi izberejo tehnološki sklop, ki najbolj ustreza njihovi posamezni vrsti poslovanja.
Ena ekipa lahko uporabi React za programiranje svojega fragmenta. Druga ekipa ustvari novo različico Angular. Vue.js je en tak primer.
Mikro vmesniki se uporabljajo v povezavi s povezanimi mikrostoritvami za reševanje težav, ki jih imajo razvojne skupine običajno z monoliti. Strategija ponuja naslednje prednosti.
- Tehnološka svoboda: Frontend inženirji lahko izberejo alternativna ogrodja JavaScript, izvajalna okolja in celotne tehnološke nize glede na potrebe podjetja. Poleg zastarele arhitekture je mogoče uporabiti nov okvir.
- Možna je večja stopnja prilagodljivosti, saj je vsak mikro vmesnik samostojen in ga je mogoče razviti, preizkusiti, uvesti in nadgraditi ločeno. Posledično, če ena ekipa dela na funkciji in je potisnila popravek napake, druga ekipa pa mora dodati svojo lastno funkcijo, jim ni treba čakati, da prva ekipa dokonča svojo nalogo.
- Avtonomne ekipe in sistemi: Vsaka ekipa izdelka in posledično vsaka funkcija lahko deluje z majhno odvisnostjo od drugih, kar ji omogoča, da nadaljuje z delom, tudi če bližnje komponente niso na voljo.
- Več, manjših baz kode: Vsaka od mikro vtičnic bo imela svojo, bolj obvladljivo, manjšo bazo kode. Manj ljudi se bo osredotočilo na določeno komponento uporabniškega vmesnika, poenostavilo preglede kode in izboljšalo splošno organizacijo.
- Enostavno skaliranje aplikacije: Druga prednost mikro vmesnikov je zmožnost skaliranja vsake funkcije posebej. V nasprotju z monoliti, kjer je treba celoten program povečati vsakič, ko je dodana nova funkcija, je zaradi tega celoten postopek bolj učinkovit v smislu časa in denarja.
Kako deluje mikro vmesnik?
Kot smo že omenili, so ekipe vertikalno organizirane znotraj arhitekture mikro vmesnika, kar pomeni, da so ločene glede na znanje domene ali namen in so odgovorne od začetka do konca za določen izdelek.
Lahko ima eno ali dve zaledni mikrostoritvi, pa tudi majhno sprednjo stran. Podrobneje preučimo značilnosti tega vizualnega elementa, interakcije z drugimi komponentami uporabniškega vmesnika in vključitev v domačo stran.
Mikro frontend je lahko
- celotno stran (npr. stran s podrobnostmi o izdelku) oz
- razdelke strani, ki jih lahko uporabljajo druge ekipe, kot so glave, noge in iskalne vrstice.
Veliko spletno stran lahko razdelite na več vrst strani in vsako vrsto daste določenemu osebju, da dela na njej.
Vendar pa se več komponent pogosto pojavlja na številnih straneh, kot so glave, noge, bloki predlogov itd. Blok predlogov je na primer lahko vključen na domačo stran, stran s podrobnostmi o izdelku ali celo stran za dokončanje nakupa.
V bistvu lahko ekipe ustvarijo dele, ki jih lahko druge ekipe uporabijo na svojih straneh.
Mikro vmesnike pa je mogoče namestiti ločeno kot različne projekte v nasprotju s komponentami za večkratno uporabo.
Vse to se sliši fantastično, a za ustvarjanje enotnega vmesnika je treba strani in fragmente nekako združiti.
To zahteva integracijo sprednjega dela, ki jo je mogoče doseči z različnimi strategijami, vključno z usmerjanjem, sestavljanjem in komunikacijo (glejte zgornjo grafiko).
Usmerjanje
Ko je za dostop do strani, ki je v lasti druge ekipe, potrebna storitev s strani, ki jo nadzoruje ena ekipa, je usmerjanje uporabno za integracijo na ravni strani.
Vsak mikro vmesnik se obravnava kot enostranska aplikacija. Za zagotavljanje usmerjanja je mogoče uporabiti preproste povezave HTML.
Uporabnik lahko s klikom na hiperpovezave prisili brskalnik, da prenese ciljno oznako s strežnika in zamenja trenutno stran z novo.
Lupina aplikacije je minimum HTML, CSS in JavaScript, ki poganja uporabniški vmesnik. Tudi če podatki o vsebini, zahtevani od strežnika, še vedno čakajo, uporabnik takoj prejme statično prikazano stran. Osrednja aplikacijska lupina služi kot nadrejena aplikacija za enostranske aplikacije, ki jih ustvarijo različne ekipe.
Ne glede na knjižnico ali ogrodje, ki se uporablja, meta-ogrodja omogočajo zlitje različnih strani v eno samo.
sestava
Kompozicija je postopek razvrščanja delov, da se prilegajo ustreznim prostorom na strani. V večini primerov ekipa, ki postavi stran, ne pridobi takoj vsebine fragmenta.
Namesto tega postavi ogrado ali oznako, kjer bi moral biti fragment v oznaki.
Z uporabo drugačnega postopka sestavljanja je končna montaža dosežena. Sestavo lahko razdelimo v dve osnovni kategoriji: na strani odjemalca in na strani strežnika.
Sestava na strani odjemalca: Spletni brskalnik se uporablja za ustvarjanje in urejanje oznak HTML. Vsak mikro vmesnik ima možnost spreminjanja in prikazovanja oznak ločeno od preostale strani.
Spletne komponente vam na primer omogočajo izvedbo te vrste gradnje.
Načrt je, da se vsak fragment spremeni v spletno komponento, ki jo je mogoče neodvisno namestiti kot datoteko a.js, nato pa jih lahko aplikacije naložijo in upodabljajo v prostorih, ki so zanje določeni v postavitvi teme.
Spletne komponente so odvisne od API-ja HTML in DOM, ki ju lahko uporabljajo druga ogrodja frontend, kot tudi od standardne metode pošiljanja in prejemanja podatkov prek rekvizitov in dogodkov.
Sestava na strani strežnika: Pri tej zasnovi so deli uporabniškega vmesnika združeni na strežniku, kar ima za posledico popolnoma oblikovano stran, poslano na stran odjemalca, kar pospeši nalaganje.
Sestavljanje pogosto izvaja ločena storitev, ki se nahaja med spletnim brskalnikom in spletnimi strežniki. CDN je en primerek storitve (omrežje za dostavo vsebin).
Lahko izberete enega ali kombinacijo obeh, odvisno od vaših potreb.
Mikro frontend komunikacijski vzorci
Arhitektura mikro-frontend deluje najbolje, ko med različnimi komponentami ni interakcije ali je le malo. Mikro vmesniki se morajo občasno pogovarjati med seboj in izmenjevati informacije. Tukaj je nekaj možnih vzorcev, ki bi lahko vodili do tega.
- Spletni delavci: Spletni delavec je mehanizem, ki spletni vsebini omogoča izvajanje JavaScripta v ozadju, neodvisno od drugih skriptov in brez vpliva na hitrost strani. Za vsako mikro aplikacijo bo na voljo edinstven API za delavce. Ta prednost je, da je zamudno delo mogoče opraviti v drugi niti, kar omogoča, da nit uporabniškega vmesnika nadaljuje, ne da bi bila upočasnjena ali ustavljena.
- Oddajnik dogodkov: V tem primeru številne komponente med seboj komunicirajo tako, da poslušajo in ukrepajo na kakršne koli spremembe stanja v komponentah, na katere so naročene. Drugi mikro vmesniki, ki so naročeni na ta določen dogodek, se odzovejo, ko mikro vmesnik sproži ta dogodek. Oddajnik dogodkov, ki je bil uveden v vsako mikrosprednjo stran, omogoča, da je to izvedljivo.
- Povratni klici in rekviziti: V tem razdelku definirate nadrejeno komponento in podrejene komponente. Komunikacija je organizirana v drevesno strukturo. Nadrejene komponente uporabljajo rekvizite za prenos podatkov kot funkcij navzdol po drevesu komponent do podrejenih komponent. Po drugi strani pa lahko otrok učinkovito opozori starša, ko se kaj zgodi v njegovem stanju, tako da se odzove na povratne klice. React uporablja ta način.
Prednosti mikro vmesnika
Razvoj v hitro avtonomnih ekipah
Neodvisna ekipa lahko ustvari vsak del spletne aplikacije ali spletnega mesta, ko uporablja metodo mikro vmesnika.
Vsaka ekipa je popolnoma avtonomna, kar pomeni, da je zadolžena za celoten cikel razvoja komponent, od zasnove do izdaje in postprodukcije.
Poleg tega pomeni, da lahko različne ekipe nemoteno sodelujejo, medtem ko istočasno delajo na istem projektu.
Zato so cikli sproščanja bistveno hitrejši, kot bi bili pri sprednjih monolitih.
Manjše kodne baze posameznih mikro vmesnikov vodijo do čistejše kode
Monolitni sprednji deli imajo velike, okorne kodne baze, ki sčasoma postajajo vse bolj kaotične in zahtevne za upravljanje.
Mikro vmesniki rešujejo to težavo. Vsaka izvorna koda mikro vmesnika je bolj obvladljiva, saj je manjša, preprostejša in kompaktnejša.
Celotna spletna rešitev ima posledično koristi od čistejše kode.
Izboljšana stabilnost aplikacije zaradi ohlapne povezave
Spletno rešitev je redkokdaj mogoče razdeliti na popolnoma neodvisne dele. Posledično se mikro vmesniki med seboj pogovarjajo.
Vendar je vsaka povezava med komponentami pomembna kljub ohlapni povezljivosti.
Okvara ene komponente skoraj nič ne vpliva na delovanje vseh ostalih komponent, kar zagotavlja večjo stabilnost spletne rešitve.
Preizkušanje posameznih funkcij je poenostavljeno
Ta prednost izhaja iz značilnosti mikro vmesnikov. Na podlagi te arhitekturne zasnove je odjemalska stran spletne rešitve modularna in vsak modul je avtonomen.
Posledično je za ekipo lažje oceniti majhen del uporabniškega vmesnika kot testirati ogromen monolit.
Zmanjšana velikost paketa vodi do hitrejšega nalaganja strani
Eden glavnih vzrokov za zakasnjene čase nalaganja v monolitnih spletnih sistemih, bogatih s funkcijami, je velikost svežnja JavaScript. Po drugi strani pristop mikro frontend olajša skrajšanje časa nalaganja strani.
Brskalniku ni treba vedno znova prenašati nepotrebne kode, saj je spletna stran sestavljena iz več majhnih svežnjev. Posledično se poveča učinkovitost strani in čas nalaganja.
Tehnološka neodvisnost
Večkraten front-end okvirji razvijalci lahko uporabijo za ustvarjanje ene same spletne rešitve z mikro-frontend arhitekturo.
Ker je vsaka komponenta avtonomna, jo je mogoče sestaviti s tehnologijo, ki najbolj ustreza nalogam ekipe.
Programerji morajo seveda biti previdni pri izbiri ogrodij za projekt programske opreme, ki ga vodijo, posvetovanje z drugimi ekipami pa je še vedno močno priporočljivo.
Vendar ni nobene možnosti, da boste prisiljeni uporabljati podedovano ogrodje v času trajanja aplikacije.
Slabosti Micro Frontend
Testiranje kompleksne spletne rešitve v celoti
Preizkušanje različnih modulov spletne rešitve je preprosto, če uporablja arhitekturo mikro-čelja. Vendar se razlikuje od ocenjevanja spletne aplikacije kot celote.
Pred nadaljevanjem preverite, ali vsi deli delujejo, kot je predvideno. To bi lahko bilo težko, saj mikro vmesniki delujejo neodvisno in imajo ločene postopke dostave.
Drage začetne naložbe
Razvoj mikro vmesnikov običajno zahteva znatne finančne izdatke. Drago je sestaviti in vzdrževati številne front-end ekipe.
Poleg tega boste potrebovali vodstveno osebje, ki bo organiziralo delo, poskrbelo, da bo vse usklajeno, in zagotovilo odlično komunikacijo v skupini.
Kompleksnost razvoja in uvajanja
Postopki razvoja in uvajanja lahko postanejo bolj zapleteni zaradi zasnove mikročela.
Neodvisne razvojne ekipe, ki delajo na istem projektu, bi lahko na primer rešitev napolnile s preveč komponentami, kar bi lahko povzročilo težave v fazi uvajanja.
Tudi pravilna montaža vseh modulov in njihova nemotena integracija v celotno shemo ni vedno enostavna; to delo običajno zahteva temeljito razumevanje vseh odvisnosti.
Težave pri ohranjanju skladnosti v uporabniški izkušnji
Vzdrževanje doslednega uporabniškega vmesnika je izziv, ko ekipe ločeno delajo na več delih programske opreme.
Spletno rešitev bi si morali deliti vsi razvijalci projekta. V nasprotnem primeru je lahko na poti veliko nasprotij.
zaključek
Microfrontends, sodobna arhitekturna zasnova, lahko močno povečajo učinkovitost obsežnih projektov spletnega razvoja, ki temeljijo na mikrostoritvah.
Programerjem omogoča, da celotno rešitev razdelijo na ločene dele, ki jih lahko ustvari več avtonomnih ekip. Iz tega izhajajo številne prednosti, vključno s hitrejšim uvajanjem funkcij, lažjim testiranjem posameznih modulov in bolj brezhibnimi nadgradnjami.
Vendar pa je nekaj težav tudi z mikro vmesniki.
Izčrpno testiranje aplikacije je lahko na primer zahtevno.
Ker je potrebna velika ekipa inženirjev in skrbnikov, so projekti mikro vmesnikov zelo dragi.
Zato morate pred odločitvijo upoštevati vse komponente vašega poslovnega primera.
Vladimír Čamaj
Nekako mi ni bilo jasno, po kakšnem principu deluje komunikacija med posameznimi komponentami na frontendu. Ne razumem, kako želite povezati komponente, ki so ustvarjene v različnih okvirih. V članku o tem ni ničesar. Sistem dogodkov in poslušalcev se mi zdi kot pekel na zemlji. Kako naj si to predstavljamo?