Efnisyfirlit[Fela][Sýna]
Hugmyndin um örþjónustu hefur vakið mikla athygli að undanförnu og mörg fyrirtæki nota hana til að losa sig við stóra, einhæfa bakenda.
Að fara sömu leið með framendanum er enn áskorun fyrir mörg fyrirtæki, jafnvel þótt þessi dreifða leið til að smíða netþjónahlið vefforrita sé meira og minna áreiðanleg hvað varðar rannsóknir og framkvæmd.
Vegna þess hve háð því er, gerir einhliða viðskiptavinurinn það venjulega erfitt að samþætta nýja eiginleika, taka upp nýja tækni og skala einstaka íhluti.
Þessar og aðrar áskoranir hafa orðið til þess að framenda verktaki til að rannsaka notkun örþjónustu.
Fyrir vikið var glæný arkitektúrstefna, þekkt sem ör framhlið, þróuð til að búa til framhliðarlag vefsíðna og vefforrita.
Hugtakið var fyrst notað árið 2016 og síðan þá hefur það vakið mikla athygli fyrir gott málefni.
Þessi grein mun gefa almennan skilning á því hvað örviðmót eru og vandamálin sem þeir taka á. það er að virka, sem og kostir og gallar.
Kynning á örframhliðararkitektúr
Nútíma aðferð við framhliðarþróun sem kallast ör-framenda arkitektúr skiptir a vefumsókn í litla, sjálfstæða hluta.
Fyrir endanotandann virðast þessir hlutar vera ein eining jafnvel þótt þeir hafi verið smíðaðir sjálfstætt og síðan settir saman.
Með þeim mun að örframendingar snerta viðskiptavinahlið, ekki netþjónahlið, netlausna, þá eru rökin sem liggja að baki þeim eins og örþjónustur.
Það er skynsamlegast að búa til háþróaðar vörur á netinu þegar örframendaaðferð er notuð.
Örframendingar, öfugt við hefðbundnari framenda-einlit, gera mörgum teymum kleift að vinna sérstaklega að ýmsum hugbúnaðarverkefnum.
Forritarar geta búið til vefforrit hraðar og með meiri sveigjanleika og viðhaldshæfni með því að nota þessa byggingarhönnun.
Til að setja það einfaldlega, er hver örframhlið bara stykki af kóða fyrir sérstakan hluta vefsíðunnar.
Þessum eiginleikum er stjórnað af sérstökum teymum, sem hvert um sig sérhæfir sig í ákveðnum iðnaði eða markmiði.
Monolithic vs Microservices vs Micro frontend arkitektúr
Hugsaðu þér að flytja. Verður einfaldara fyrir þig að skipuleggja allt í nokkra litla, faglega merkta kassa og flytja hvern og einn fyrir sig eða pakka öllu starfsfólkinu í einn risastóran kassa og flytja það á nýjan stað?
Augljósa lausnin er til staðar.
Þessi samlíking ber saman tvo aðskilda vefforritaarkitektúra, einlita og örþjónustur (einnig þekktar sem örframhliðar).
Einhverfa byggingarlist
Þú gætir kannski rifjað upp „gömlu góðu dagana“ þegar heilt forrit var búið til sem ein heildstæð heild. Slík aðferð er kölluð monolith, sem er gamalt orð yfir stóra steinblokk.
Þetta er skynsamlegt.
Einhverfa kerfi hafa innbyrðis háða þætti. Þess vegna, ef þú vilt breyta einhverju eða bæta við nýjum eiginleika, er mögulegt að allt kerfið geti bilað.
Jafnvel þó að það sé úrelt er það stundum enn til. Já, við erum meðvituð um núverandi tjáningu þína.
Hugmyndaleg skipting kóðagrunnsins í tvo mismunandi þætti - framenda (viðskiptavinamegin) og bakendi (miðlarahlið) - varð óumflýjanleg þar sem ný tækni þróaðist og hugbúnaðarvörur urðu flóknari.
Vinsælasta aðgerðaaðferðin er nú aðskilnaður áhyggjuefna á milli kynningarlagsins sem notandi hefur samskipti við og alls sem á sér stað í bakgrunni.
Það þarf tvö hugbúnaðarverkfræðiteymi, þar sem framhliðarteymið byggir sjónrænu íhlutina og bakhliðarteymið byggir upp vefþjónustuna, viðskiptarökfræði, gagnaaðgang, samþættingu osfrv.
En þrátt fyrir þennan aðskilnað er þessi stefna enn einhlít í eðli sínu.
Helsta breytingin er sú að við erum núna með tvo stóra kóðablokka – framenda og bakendann – í stað eins stórs forrits. Monolithic arkitektúr þarf ekki að vera hræðilegt; þeir hafa nokkra kosti, þar á meðal
- Einföld og fljótleg þróun fyrir örsmá forrit með einum frumkóðagrunni og mjög einfaldri hönnun;
- Prófun og villuleit eru mjög einföld vegna þess að allur kóði er á einum stað, sem auðveldar teymi að fylgjast með flæði beiðni og bera kennsl á villur;
- Snemma í þróun forrits eru útgjöld ódýrari þar sem hvorki innviðakostnaður né þróunarkostnaður fellur til fyrr en nýjum eiginleikum er bætt við.
Gallarnir við þessa stefnu endurspeglast í
- Takmarkaður sveigjanleiki í dreifingu - teymi verða að bíða ef aðeins örfáir þeirra eru að vinna að verkefninu og ný uppsetning er nauðsynleg í hvert skipti sem þú uppfærir kóðann;
- Það er krefjandi að taka upp nýja tækni þar sem það þarf að endurskrifa verulegan hluta, ef ekki allt verkefnið.
- Þegar þróunaraðilum fjölgar verður kóðakerfi nátengt, flókið og erfitt að stjórna og skilja.
- Skipulagsvandamál - hver teymi verður að nota sömu útgáfu af bókasöfnum og tilkynna allar breytingar ef mörg teymi eru að vinna að einhæfu verkefni.
- Áhyggjur af sveigjanleika – vegna þess að þættir verkefnisins eru samtengdir, veldur því að skala þá sérstaklega erfiðleika sem hafa í för með sér umtalsverðan niðurtíma og meiri útgjöld.
- Flókin rökfræði verkefnisins gæti verið erfið fyrir nýja liðsmenn að skilja, sérstaklega ef verkfræðingarnir sem upphaflega unnu að því eru ekki lengur starfandi.
Þróun örþjónustu og náinna ættingja þeirra, og örframenda, tók á aðalvandamálum einhæfra kerfa.
Örþjónustuarkitektúr
Byggingaraðferðin, þekkt sem örþjónustur, gerir kleift að búa til marga lauslega tengda og sjálfstætt dreifanlega smærri íhluti, eða þjónustu, sem mynda stuðning forrits.
Sérhver þjónusta hefur sinn eigin kóðagrunn, CI/CD leiðslur, DevOps verklagsreglur og ferla til að keyra þær.
Þú getur séð að einlita bakendateyminu er skipt í aðskilin lið með því að skoða myndina hér að ofan.
Hver einbeitir sér að öðrum þáttum forritsins (svo sem vöruþjónustu, leitarþjónustu og greiðsluþjónustu).
Samskipti milli þjónustunnar eiga sér stað í gegnum staðfestar samskiptareglur þekktar sem API, svo sem létt REST API samskiptareglur sem notar samstillt beiðni-svar mynstur.
Annar valkostur er að nota ósamstillt samskipti með því að nota hugbúnað eins og Kafka, sem býður upp á samskiptakerfi og viðburði til að birta/ gerast áskrifandi.
Örþjónustur samþættast framendanum í gegnum bakenda fyrir framendaþjónustuna (BFF) eða API hlið í gegnum netið. BFF býður upp á sérsniðið API fyrir hvern viðskiptavin, en API hlið veita einum aðgangsstað fyrir safn af örþjónustum.
En jafnvel með sjálfstæða bakendahluti og alla þá kosti sem þeir veita, er framhliðin samt einhliða.
Þess vegna er þetta þar sem örframhliðar eru gagnlegar.
Ör framenda arkitektúr
Svipað og örþjónustur, þar sem lauslega tengdir íhlutir eru stjórnaðir af nokkrum teymum, beitir örframenda arkitektúr hugmyndinni á vafrann.
Þessi notendaviðmót vefforrita fylgja þessari uppbyggingu, sem samanstendur af nokkuð sjálfstæðum hlutum.
Teymi eru einnig búin til á þörfum viðskiptavinarins eða notkunartilvikum frekar en sérfræðiþekkingu eða tækni.
Þar af leiðandi taka teymi þátt í örþjónustu og örframendaverkefnum.
- lóðrétt sneið - þar sem það eru framendaframleiðendur, gagnasérfræðingar, bakendaverkfræðingar, QA verkfræðingar o.s.frv. sem vinna að sama verkefninu, búa þeir til eiginleika sína úr notendaviðmót til gagnagrunna; og
- þvervirkni – hver liðsmaður leggur til sérfræðiþekkingu sína til hópsins.
Teymi geta líka valið þann tæknistafla sem hentar best tilteknu viðskiptasviði þeirra.
Eitt lið getur notað React til að forrita brot sitt. Annað lið býr til nýja Angular útgáfu. Vue.js er eitt slíkt dæmi.
Ör framendingar eru notaðir í tengslum við tengda örþjónustu til að takast á við vandamál sem þróunarteymi hafa venjulega með einlita. Stefnan býður upp á eftirfarandi kosti.
- Tæknifrelsi: Framendaverkfræðingar geta valið aðra JavaScript ramma, keyrsluumhverfi og heila tæknistafla eftir þörfum fyrirtækisins. Ofan á úreltan arkitektúr gæti verið beitt nýjum ramma.
- Meiri sveigjanleiki er mögulegur þar sem hver örframenda er sjálfstætt og hægt er að þróa, prófa, dreifa og uppfæra sérstaklega. Þar af leiðandi, ef eitt teymi er að vinna að eiginleikum og hefur ýtt á villuleiðréttingu, og annað lið þarf að bæta við eigin eiginleika, þá þarf það ekki að bíða eftir að fyrsta liðið ljúki verkefni sínu.
- Sjálfstætt teymi og kerfi: Hvert vöruteymi, og þar af leiðandi hver eiginleiki, getur virkað með litlum ósjálfstæði á öðrum, sem gerir það kleift að halda áfram að vinna jafnvel þegar nærliggjandi íhlutir eru ekki tiltækir.
- Margir, smærri kóðabasar: Hver örframenda mun hafa sinn eigin, meðfærilegri, minni kóðagrunn. Færri munu einbeita sér að tilteknum notendahluta, einfalda kóðadóma og bæta heildarskipulagið.
- Einföld forritsstærð: Annar ávinningur við örframenda er hæfileikinn til að skala hvern eiginleika fyrir sig. Öfugt við einlita, þar sem þarf að stækka allt forritið í hvert skipti sem nýjum eiginleika er bætt við, gerir þetta allt ferlið skilvirkara bæði hvað varðar tíma og peninga.
Hvernig virkar micro frontend?
Eins og við höfum áður sagt eru teymi lóðrétt skipulögð innan örframenda arkitektúrsins, sem þýðir að þau eru aðskilin af lénsþekkingu eða tilgangi og bera ábyrgð frá upphafi til enda fyrir tiltekna vöru.
Það getur verið með eina eða tvær bakenda örþjónustur sem og lítinn framenda. Nánar skulum við skoða eiginleika þessa sjónræna þáttar, samskipti við aðra HÍ íhluti og innlimun á heimasíðuna.
Ör framhlið getur verið
- heila síðu (td upplýsingar um vöru) eða
- hluta síðunnar sem hægt er að nota af öðrum teymum, svo sem hausa, fóta og leitarstikur.
Þú getur skipt upp stórri vefsíðu í nokkrar síðutegundir og gefið tilteknu starfsfólki hverja tegund til að vinna á.
Hins vegar koma oft nokkrir þættir fyrir á fjölmörgum síðum, svo sem hausar, síðufætur, tillögublokkir o.s.frv. Tillögublokk, til dæmis, getur verið með á heimasíðu, vöruupplýsingasíðu eða jafnvel afgreiðslusíðu.
Í meginatriðum geta lið búið til verk sem önnur lið geta notað á síðum sínum.
Hins vegar er hægt að nota örframendana sérstaklega sem mismunandi verkefni öfugt við endurnotanlega íhlutina.
Allt þetta hljómar frábærlega, en til að búa til sameinað viðmót þarf einhvern veginn að sameina síður og brot.
Þetta krefst samþættingar framenda, sem hægt er að ná með ýmsum aðferðum, þar á meðal leið, samsetningu og samskiptum (sjá mynd hér að ofan).
Bankanúmer
Þegar þjónusta frá síðu sem stjórnað er af einu teymi er nauðsynleg til að fá aðgang að síðu í eigu annars liðs, er leiðin gagnleg fyrir samþættingu á síðustigi.
Sérhver ör framhlið er meðhöndluð sem forrit á einni síðu. Einfalda HTML tengla er hægt að nota til að veita leið.
Notandi getur þvingað vafrann til að hlaða niður markmerkingunni af netþjóni og skipt út núverandi síðu fyrir nýja með því að smella á tengla.
App skelin er lágmarks HTML, CSS og JavaScript sem knýr notendaviðmót. Jafnvel þó að innihaldsgögnin sem beðið er um frá þjóninum bíða enn, fær notandinn kyrrstæða birta síðu strax. Miðja app skelin þjónar sem foreldraforrit fyrir einni síðu öpp sem búin eru til af hinum ýmsu teymum.
Sama hvaða bókasafn eða ramma er notað, meta-frameworks gera kleift að sameina ýmsar síður í eina.
samsetning
Samsetning er ferlið við að raða verkunum þannig að þeir passi í viðeigandi rými á síðu. Í flestum tilfellum sækir teymið sem setur síðuna ekki strax innihald brotsins.
Þess í stað setur það staðgengill eða merki þar sem brotið ætti að vera í merkingunni.
Með því að nota annað samsetningarferli er lokasamsetningin lokið. Hægt er að skipta samsetningunni í tvo grunnflokka: viðskiptavinahlið og miðlarahlið.
Samsetning viðskiptavinarhliðar: Vafrinn er notaður til að búa til og breyta HTML merkingu. Hver örframenda hefur getu til að breyta og sýna merkingu sína aðskilið frá restinni af síðunni.
Vefhlutir, til dæmis, gera þér kleift að framkvæma þessa tegund af byggingu.
Ætlunin er að breyta hverju broti í vefhluta sem hægt er að setja upp sjálfstætt sem a.js skrá, eftir það geta öppin hlaðið og endurnýjað þau í þeim rýmum sem tilgreind eru fyrir þau í þemauppsetningunni.
Vefhlutir eru háðir HTML og DOM API, sem aðrir framenda rammar geta notað, sem og staðlaða aðferð til að senda og taka á móti gögnum í gegnum leikmuni og atburði.
Samsetning miðlara: Með þessari hönnun eru UI-hlutarnir sameinaðir á þjóninum, sem leiðir til þess að fullmótuð síða er send til viðskiptavinarhliðarinnar, sem flýtir fyrir hleðslu.
Samsetningin er oft framkvæmd af sérstakri þjónustu sem situr á milli vafrans og vefþjónanna. CDN er eitt tilvik þjónustunnar (efnisafhendingarnet).
Þú gætir valið einn eða blöndu af þessu tvennu, allt eftir þörfum þínum.
Ör framenda samskiptamynstur
Ör-framenda arkitektúrinn virkar best þegar það er lítil sem engin samspil milli hinna ýmsu íhluta. Örframendingar þurfa stundum að tala saman og deila upplýsingum. Hér eru nokkur möguleg mynstur sem gætu leitt til þess.
- Vefstarfsmenn: Starfsmaður á netinu er vélbúnaður sem gerir vefefni kleift að keyra JavaScript í bakgrunni, óháð öðrum forskriftum, og án þess að hafa áhrif á hraða síðunnar. Einstakt forritaskil starfsmanna verður veitt fyrir hvert örforrit. Þessi ávinningur er sá að hægt er að vinna tímafrekt verk í öðrum þræði, sem gerir HÍ þráðnum kleift að halda áfram án þess að hægja á eða stöðva.
- Atburðargeisli: Í þessu tilviki hafa margir íhlutir samskipti sín á milli með því að hlusta á og bregðast við hvers kyns ástandsbreytingum á íhlutunum sem þeir eru áskrifendur að. Aðrir örviðmót sem hafa gerst áskrifandi að þessum tiltekna atburði bregðast við þegar örviðmót ræsir þann atburð. Atburðarsmitari sem hefur verið kynntur í hvern örframenda gerir þetta framkvæmanlegt.
- Hringingar og leikmunir: Í þessum hluta skilgreinir þú yfiríhlut og undirhluta. Samskiptin eru skipulögð í trjálíka uppbyggingu. Foreldrihlutir nota leikmuni til að koma gögnunum á framfæri sem aðgerðir niður íhlutatréð til undirhlutanna. Aftur á móti getur barnið á skilvirkan hátt látið foreldrið vita þegar eitthvað gerist í ástandi þess með því að svara svarhringingum. React notar þessa stillingu.
Kostir Micro framenda
Þróun í hröðum sjálfstæðum teymum
Óháð teymi getur búið til hvern hluta af vefforriti eða vefsíðu þegar notað er örframendaaðferð.
Hvert lið er algjörlega sjálfstætt, sem þýðir að það hefur umsjón með öllu þróunarferli íhluta, frá getnaði til útgáfu og eftirvinnslu.
Að auki felur það í sér að ýmis teymi geta unnið óaðfinnanlega samhliða því að vinna að sama verkefninu.
Þess vegna eru losunarlotur umtalsvert hraðari en þeir myndu vera með framhliða einlitum.
Minni kóðabasar einstakra örframenda leiða til hreinni kóða
Einhverfa framendarnir eru með stóra, ómeðhöndlaða kóðabasa sem verða sífellt óskipulegri og krefjandi í umsjón með tímanum.
Micro frontends taka á þessu vandamáli. Frumkóði hvers örframenda er viðráðanlegri þar sem hann er minni, einfaldari og þéttari.
Heildarveflausnin nýtur góðs af hreinni kóða í kjölfarið.
Bættur stöðugleiki forritsins vegna lausrar tengingar
Veflausn er sjaldan hægt að skipta í algjörlega sjálfstæða hluta. Þar af leiðandi tala örframendingar sín á milli.
Hins vegar er hver tenging á milli íhlutanna mikilvæg þrátt fyrir lausa tengingu.
Bilun í einum íhluta hefur lítil sem engin áhrif á rekstur allra hinna íhlutanna, sem veitir aukinn stöðugleika veflausnar.
Að prófa einstaka eiginleika er gert einfaldara
Þessi ávinningur stafar af eiginleikum örframenda. Byggt á þessari byggingarhönnun er viðskiptavinahlið veflausnar mát og hver eining er sjálfstæð.
Fyrir vikið er auðveldara fyrir teymi að meta lítinn hluta notendaviðmótsins í sjálfu sér en að prófa gríðarlegan einliða.
Minni búntastærð leiðir til hraðari síðuhleðslu
Ein helsta ástæðan fyrir seinkuðum hleðslutíma í einhæfum vefkerfum sem eru rík af eiginleikum er stærð JavaScript búnts. Á hinni hliðinni gerir örframendaaðferð það auðveldara að draga úr hleðslutíma síðu.
Vafri þarf ekki að hlaða niður óþarfa kóða ítrekað þar sem vefsíða er samsett úr nokkrum pínulitlum búntum. Fyrir vikið eykst árangur síðu og hleðslutími.
Tæknisjálfstæði
Multiple framenda ramma er hægt að nota af forriturum til að búa til eina netlausn með örframenda arkitektúr.
Þar sem hver íhluti er sjálfstæður er hægt að smíða hann með því að nota hvaða tækni sem hentar verkefnum liðsins best.
Auðvitað ættu forritarar að gæta varúðar þegar þeir velja ramma fyrir hugbúnaðarverkefnið sem þeir hafa umsjón með og enn er eindregið ráðlagt að hafa samráð við önnur teymi.
Hins vegar eru engar líkur á því að þú verðir neyddur til að nota eldri ramma meðan á líftíma appsins stendur.
Gallar við Micro Frontend
Flókin veflausnaprófun í heild sinni
Auðvelt er að prófa ýmsar einingar veflausnar þegar hún notar ör-framenda arkitektúr. Það er þó frábrugðið því að meta vefforrit í heild sinni.
Gakktu úr skugga um að allir hlutar virki eins og til er ætlast áður en þú heldur áfram. Þetta gæti verið erfitt þar sem örframendingar starfa sjálfstætt og hafa aðskilin afhendingarferli.
Dýrar stofnfjárfestingar
Örframendaþróun krefst venjulega umtalsverðs fjárútláts. Það er dýrt að setja saman og halda uppi mörgum fremstu liðum.
Að auki þarftu stjórnendur til að skipuleggja starfið, ganga úr skugga um að allt sé samræmt og tryggja framúrskarandi teymissamskipti.
Flækjustig þróunar og dreifingar
Þróunar- og dreifingarferli geta orðið flóknari vegna ör-framendahönnunar.
Lausn gæti verið ringulreið með of mörgum íhlutum af óháðum þróunarteymi sem vinna að sama verkefni, til dæmis, sem gæti valdið vandamálum á dreifingarstigi.
Rétt samsetning allra eininga og mjúk samþætting þeirra inn í heildarkerfið er heldur ekki alltaf einföld; þetta verk krefst venjulega ítarlegrar skilnings á öllum ósjálfstæðum.
Vandamál við að viðhalda samræmi í notendaupplifuninni
Það er krefjandi að viðhalda stöðugu notendaviðmóti þegar teymi vinna sitt í hvoru lagi á nokkrum hlutum hugbúnaðarins.
Veflausnin ætti að vera sameiginleg með öllum hönnuðum verkefnisins. Annars geta verið miklar mótsagnir á veginum.
Niðurstaða
Micro frontends, nútíma byggingarlistarhönnun, getur stórlega aukið afköst stórra vefþróunarverkefna sem byggjast á örþjónustu.
Það gerir forriturum kleift að skipta heildarlausninni í staka hluta sem hægt er að búa til af nokkrum sjálfstæðum teymum. Fjölmargir kostir fylgja þessu, þar á meðal hraðari útfærslu eiginleika, auðveldari prófun á einstökum einingum og óaðfinnanlegri uppfærslu.
En það eru líka nokkrir erfiðleikar með örframenda.
Alhliða prófun forrits gæti til dæmis verið krefjandi.
Þar að auki, vegna þess að þörf er á stóru teymi verkfræðinga og stjórnenda, eru örframendaverkefni mjög dýr.
Þar af leiðandi, áður en þú tekur ákvörðun, verður þú að taka tillit til allra þátta viðskiptamálsins þíns.
Vladimír Čamaj
Einhvern veginn skildi ég ekki á hvaða meginreglu samskipti einstakra íhluta á framendanum virka. Ég skil ekki hvernig þú vilt tengja saman íhluti sem eru búnir til í mismunandi ramma. Það er ekkert um það í greininni. Atburðakerfið og hlustendur lítur út eins og helvíti á jörðu fyrir mér. Hvernig ættum við að ímynda okkur það?