Përmbajtje[Fshih][Shfaqje]
- Hyrje në arkitekturën mikro-përparëse
Të mirat e Micro frontend +-
- Zhvillimi në ekipet autonome të shpejtë
- Bazat më të vogla të kodeve të mikro fronteve individuale çojnë në kod më të pastër
- Stabilitet i përmirësuar i aplikacionit për shkak të një lidhjeje të lirshme
- Testimi i veçorive individuale është bërë më i thjeshtë
- Madhësia e zvogëluar e paketës çon në ngarkim më të shpejtë të faqes
- Pavarësia e Teknologjisë
- Përfundim
Ideja e mikroshërbimeve ka fituar shumë vëmendje kohët e fundit dhe shumë firma po e përdorin atë për të hequr dorë nga prapambetjet e mëdha, monolitike.
Ecja në të njëjtën rrugë me frontend është ende një sfidë për shumë biznese, edhe nëse kjo mënyrë e shpërndarë e ndërtimit të aplikacioneve në ueb nga ana e serverit është pak a shumë e besueshme për sa i përket kërkimit dhe ekzekutimit.
Për shkak të varësisë së tij të ngushtë, monoliti nga ana e klientit zakonisht e bën të vështirë integrimin e veçorive të reja, miratimin e teknologjive të reja dhe shkallëzimin e komponentëve individualë.
Këto dhe sfida të tjera kanë nxitur zhvilluesit e frontendit të hetojnë duke përdorur mikroshërbime.
Si rezultat, një strategji krejt e re arkitekturore e njohur si mikro frontend u zhvillua për krijimin e shtresës së përparme të faqeve të internetit dhe aplikacioneve të bazuara në ueb.
Termi u përdor për herë të parë në vitin 2016, dhe që atëherë, ai ka marrë shumë vëmendje për një kauzë të mirë.
Ky artikull do të japë një kuptim të përgjithshëm të asaj që janë mikro frontendet dhe çështjet që ato trajtojnë. po funksionon, si dhe të mirat dhe të këqijat.
Hyrje në arkitekturën mikro-përparëse
Një metodë bashkëkohore e zhvillimit të front-endit të quajtur arkitektura mikro-frontend ndan a aplikacion në internet në pjesë të vogla, të pavarura.
Për përdoruesin përfundimtar, këto pjesë duken të jenë një njësi, edhe nëse janë ndërtuar në mënyrë të pavarur dhe më pas janë bashkuar.
Me ndryshimin që skajet mikro i përkasin anës së klientit, jo anës së serverit, të zgjidhjeve online, arsyetimi që qëndron në themel të tyre është identik me atë të mikroshërbimeve.
Krijimi i produkteve të sofistikuara të bazuara në ueb ka më shumë kuptim kur përdorni një qasje mikro frontend.
Mikro frontendet, në krahasim me një monolit më konvencional të pjesës së përparme, mundësojnë shumë ekipe të bashkëpunojnë veçmas në projekte të ndryshme softuerike.
Programuesit mund të krijojnë aplikacione ueb më shpejt dhe me shkallëzim dhe mirëmbajtje më të madhe duke përdorur këtë dizajn arkitekturor.
Për ta thënë thjesht, çdo mikro front është vetëm një pjesë kodi për një komponent të veçantë të faqes në internet.
Këto veçori kontrollohen nga ekipe të veçanta, secila prej të cilave është e specializuar në një industri ose objektiv të caktuar.
Arkitektura monolitike vs Microservices vs arkitektura e frontit mikro
Mendoni të zhvendoseni. A do të jetë më e thjeshtë për ju të organizoni gjithçka në një numër kutish të vogla të etiketuara me profesionalizëm dhe ta zhvendosni secilën veçmas ose ta paketoni të gjithë stafin në një kuti të madhe dhe ta transportoni në një vend të ri?
Zgjidhja e qartë është atje.
Kjo analogji krahason dy arkitekturat e veçanta të aplikacioneve në internet, monolitet dhe mikroshërbimet (të njohura gjithashtu si mikro frontend).
Arkitektura monolitike
Ju mund të jeni në gjendje të kujtoni "ditët e mira të vjetra" kur u krijua një aplikacion i plotë si një entitet i vetëm dhe koheziv. Një metodë e tillë quhet monolit, i cili është një term i vjetër për një bllok të madh guri.
Kjo ka kuptim.
Sistemet monolitike kanë elemente të ndërvarura. Prandaj, nëse dëshironi të modifikoni diçka ose të shtoni një veçori të re, është e mundur që i gjithë sistemi të prishet.
Edhe pse është e vjetëruar, herë pas here ende ekziston. Po, ne jemi të vetëdijshëm për shprehjen tuaj aktuale.
Ndarja konceptuale e bazës së kodeve në dy komponentë të ndryshëm - frontend (nga ana e klientit) dhe fundi (nga ana e serverit) - u bë i pashmangshëm pasi u zhvilluan teknologjitë e reja dhe produktet softuerike u ndërlikuan më shumë.
Metoda më e popullarizuar e funksionimit është tani ndarja e shqetësimeve midis shtresës së prezantimit me të cilën ndërvepron një përdorues fundor dhe gjithçkaje që ndodh në sfond.
Ajo ka nevojë për dy ekipe të inxhinierisë softuerike, me ekipin e përparmë që ndërton komponentët vizualë dhe ekipin e fundit që ndërton shërbimet e uebit, logjikën e biznesit, aksesin e të dhënave, integrimet, etj.
Megjithatë, pavarësisht nga kjo ndarje, kjo strategji mbetet ende monolit nga natyra.
Ndryshimi kryesor është se ne tani kemi dy blloqe të konsiderueshme kodi - frontend dhe backend - në vend të një aplikacioni të madh. Arkitekturat monolitike nuk duhet të jenë të tmerrshme; ato kanë disa përfitime, duke përfshirë
- Zhvillim i thjeshtë dhe i shpejtë për aplikacione të vogla me një bazë të vetme kodi burimi dhe një dizajn shumë të thjeshtë;
- Testimi dhe korrigjimi i gabimeve janë shumë të thjeshta sepse i gjithë kodi është në një vend, duke e bërë më të lehtë për një ekip të gjurmojë rrjedhën e një kërkese dhe të identifikojë gabimet;
- Në fillim të zhvillimit të një aplikacioni, shpenzimet janë më të lira pasi as kostot e infrastrukturës dhe as kostot e zhvillimit nuk kryhen derisa të shtohen veçori të reja.
Të metat e kësaj strategjie pasqyrohen në
- Fleksibilitet i kufizuar i vendosjes - ekipet duhet të presin nëse ka vetëm një pjesë të vogël të tyre që punojnë në projekt dhe vendosja e re kërkohet sa herë që përditësoni kodin;
- Adoptimi i teknologjive të reja është sfidues, pasi kjo kërkon rishkrimin e një pjese të konsiderueshme, nëse jo të gjithë projektit.
- Kur numri i zhvilluesve rritet, një sistem kodi bëhet i lidhur ngushtë, i ndërlikuar dhe i vështirë për t'u menaxhuar dhe kuptuar.
- Çështjet organizative – çdo anëtar i ekipit duhet të përdorë të njëjtin version të bibliotekave dhe të raportojë çdo ndryshim nëse shumë ekipe janë duke punuar në një projekt monolit.
- Shqetësimet me shkallëzueshmërinë – për shkak se komponentët e projektit janë të ndërlidhura, shkallëzimi i tyre veçmas paraqet vështirësi që rezultojnë në kohë të konsiderueshme joproduktive dhe shpenzime më të larta.
- Logjika komplekse e projektit mund të jetë e vështirë për t'u kuptuar nga anëtarët e rinj të ekipit, veçanërisht nëse inxhinierët që fillimisht kanë punuar në të nuk janë më të punësuar.
Zhvillimi i mikroshërbimeve dhe të afërmve të tyre të afërt, dhe mikro frontendeve, trajtuan problemet kryesore me sistemet monolitike.
Arkitektura e mikroshërbimeve
Metoda arkitekturore e njohur si mikroshërbime lejon krijimin e shumë komponentëve ose shërbimeve më të vogla të lidhura lirshëm dhe të dislokueshëm në mënyrë të pavarur, që përbëjnë një prapavijë aplikacioni.
Çdo shërbim ka bazën e vet të kodeve, tubacionet CI/CD, procedurat DevOps dhe proceset për ekzekutimin e tyre.
Ju mund të shihni se ekipi i backend-it monolit është i ndarë në ekipe të veçanta duke parë imazhin e mësipërm.
Secili fokusohet individualisht në një aspekt të ndryshëm të aplikacionit (si p.sh. shërbimi i produktit, shërbimi i kërkimit dhe shërbimi i pagesës).
Komunikimi midis shërbimeve ndodh përmes protokolleve të vendosura të njohura si API, siç është protokolli i lehtë REST API që përdor modele sinkrone të përgjigjes së kërkesës.
Një opsion tjetër është përdorimi i komunikimit asinkron duke përdorur softuer si Kafka, i cili ofron struktura dhe ngjarje komunikimi publiko/subscribe.
Mikroshërbimet integrohen me pjesën e përparme nëpërmjet një fundi për shërbimin frontend (BFF) ose një porte API përmes rrjetit. BFF ofron një API të personalizuar për çdo klient, ndërsa API Gateways japin një pikë të vetme aksesi për një koleksion mikroshërbimesh.
Por edhe me komponentët autonome të bazës së pasme dhe të gjitha avantazhet që ato ofrojnë, pjesa e përparme është ende një monolit.
Prandaj, këtu janë të dobishme elementet mikro.
Arkitektura e mikro frontendeve
Ngjashëm me mikroshërbimet, ku komponentët e lidhur lirshëm menaxhohen nga disa ekipe, arkitektura mikro frontend e zbaton konceptin në shfletues.
Këto ndërfaqe përdoruesi të aplikacioneve në ueb ndjekin këtë strukturë, e cila përbëhet nga komponentë disi autonome.
Ekipet krijohen gjithashtu për nevojat e klientëve ose rastet e përdorimit dhe jo për ekspertizë ose teknologji të veçantë.
Rrjedhimisht, ekipet janë të përfshira në mikroshërbime dhe projekte mikro frontend.
- të prera vertikalisht — pasi ka zhvillues të front-endit, ekspertë të të dhënave, inxhinierë të backend-it, inxhinierë QA, etj. që punojnë gjithashtu në të njëjtin projekt, ata krijojnë veçoritë e tyre nga Ndërfaqja e përdoruesit në bazat e të dhënave; dhe
- ndërfunksionale – secili anëtar i ekipit kontribuon me ekspertizën e tij në grup.
Ekipet mund të zgjedhin gjithashtu grupin e teknologjisë që i përshtatet më së miri linjës së tyre të veçantë të biznesit.
Një ekip mund të përdorë React për të programuar fragmentin e tij. Një ekip tjetër krijon një version të ri Angular. Vue.js është një shembull i tillë.
Mikro frontendet përdoren në lidhje me mikroshërbimet përkatëse për të adresuar çështjet që ekipet e zhvillimit zakonisht kanë me monolite. Strategjia ofron përparësitë e mëposhtme.
- Liria e teknologjisë: Inxhinierët Frontend mund të zgjedhin korniza alternative JavaScript, mjedise të kohës së funksionimit dhe grupe të tëra teknologjie në varësi të nevojave të kompanisë. Në krye të arkitekturës së vjetëruar, mund të aplikohet një kornizë e re.
- Një shkallë më e madhe fleksibiliteti është e mundur pasi çdo mikro front është i pavarur dhe mund të zhvillohet, testohet, vendoset dhe përmirësohet veçmas. Si rezultat, nëse një ekip është duke punuar në një veçori dhe ka shtyrë një rregullim të defekteve, dhe një ekip tjetër duhet të shtojë veçorinë e tij, ata nuk kanë nevojë të presin që ekipi i parë të përfundojë detyrën e tyre.
- Ekipet dhe sistemet autonome: Çdo ekip produkti, dhe rrjedhimisht çdo veçori, mund të funksionojë me pak varësi nga të tjerët, gjë që i mundëson të vazhdojë të punojë edhe kur komponentët e afërt nuk janë të disponueshëm.
- Baza e kodeve të shumëfishta, më të vogla: Secila prej mikro fronteve do të ketë bazën e vet të kodit, më të menaxhueshme dhe më të vogël. Më pak njerëz do të fokusohen në një komponent specifik të ndërfaqes së përdoruesit, do të thjeshtojnë rishikimet e kodit dhe do të përmirësojnë organizimin e përgjithshëm.
- Shkallëzimi i thjeshtë i aplikacionit: Një përfitim tjetër i mikro frontendeve është aftësia për të shkallëzuar secilën veçori individualisht. Ndryshe nga monolitet, ku i gjithë programi duhet të shkallëzohet sa herë që shtohet një veçori e re, kjo e bën të gjithë procesin më efikas si në kohë ashtu edhe në para.
Si funksionon mikro frontend?
Siç e kemi thënë më parë, ekipet janë të organizuara vertikalisht brenda arkitekturës së mikro frontendit, që do të thotë se ato janë të ndara nga njohuritë ose qëllimi i domenit dhe janë përgjegjës nga fillimi në fund për një produkt specifik.
Mund të ketë një ose dy mikroshërbime mbështetëse, si dhe një front të vogël. Më në detaje, le të shqyrtojmë karakteristikat e këtij elementi vizual, ndërveprimet me komponentët e tjerë të ndërfaqes së përdoruesit dhe përfshirjen në faqen kryesore.
Një frontend mikro mund të jetë
- një faqe të tërë (p.sh., një faqe me detaje produkti) ose
- seksionet e faqes që mund të përdoren nga ekipe të tjera, të tilla si titujt, fundet dhe shiritat e kërkimit.
Ju mund të ndani një uebsajt të madh në disa lloje faqesh dhe t'ia jepni secilit lloj një stafi specifik për të punuar.
Megjithatë, disa komponentë ndodhin shpesh në faqe të shumta, të tilla si titujt, fundet e faqeve, blloqet e sugjerimeve, etj. Një bllok sugjerimi, për shembull, mund të përfshihet në një faqe kryesore, një faqe me detaje produkti, apo edhe në faqen e arkës.
Në thelb, ekipet mund të krijojnë pjesë që ekipet e tjera mund t'i përdorin në faqet e tyre.
Mirëpo, skajet mikro mund të vendosen veçmas si projekte të ndryshme në krahasim me komponentët e ripërdorshëm.
E gjithë kjo tingëllon fantastike, por për të krijuar një ndërfaqe të unifikuar, faqet dhe fragmentet duhet disi të kombinohen.
Kjo kërkon integrim në front, i cili mund të realizohet nëpërmjet një sërë strategjish, duke përfshirë rrugëzimin, përbërjen dhe komunikimin (shih grafikun e mësipërm).
Kurs
Kur shërbimi nga një faqe e kontrolluar nga një ekip kërkohet për të hyrë në një faqe në pronësi të një ekipi tjetër, rutimi është i dobishëm për integrimin në nivel faqeje.
Çdo mikro front trajtohet si një aplikacion me një faqe. Lidhje të thjeshta HTML mund të përdoren për të ofruar rrugëzim.
Një përdorues mund ta detyrojë shfletuesin të shkarkojë shënimin e synuar nga një server dhe të zëvendësojë faqen aktuale me një të re duke klikuar mbi lidhjet.
Predha e aplikacionit është minimumi i thjeshtë i HTML, CSS dhe JavaScript që fuqizon një ndërfaqe. Edhe nëse të dhënat e përmbajtjes të kërkuara nga serveri janë ende në pritje, përdoruesi merr menjëherë një faqe të shfaqur statike. Predha qendrore e aplikacionit shërben si një aplikacion prind për aplikacionet me një faqe të krijuar nga ekipe të ndryshme.
Pavarësisht nga biblioteka ose korniza që përdoret, meta-kornizat mundësojnë shkrirjen e faqeve të ndryshme në një të vetme.
përbërje
Kompozimi është procesi i renditjes së pjesëve për t'i vendosur ato në hapësirat e duhura në një faqe. Në shumicën e rasteve, ekipi që vendos faqen nuk e merr menjëherë përmbajtjen e fragmentit.
Në vend të kësaj, vendos një vendmbajtes ose shënues ku fragmenti duhet të jetë në shënim.
Duke përdorur një proces të ndryshëm kompozimi, kryhet montimi përfundimtar. Përbërja mund të ndahet në dy kategori themelore: nga ana e klientit dhe nga ana e serverit.
Përbërja nga ana e klientit: Shfletuesi i internetit përdoret për të krijuar dhe modifikuar shënjimin HTML. Çdo mikro front ka aftësinë të ndryshojë dhe të tregojë shënimin e tij veçmas nga pjesa tjetër e faqes.
Komponentët e Uebit, për shembull, ju lejojnë të kryeni këtë lloj ndërtimi.
Plani është që çdo fragment të kthehet në një komponent ueb që mund të instalohet në mënyrë të pavarur si një skedar a.js, pas së cilës aplikacionet mund t'i ngarkojnë dhe t'i shfaqin ato në hapësirat e caktuara për ta në paraqitjen e temës.
Komponentët e uebit varen nga HTML dhe DOM API, të cilat kornizat e tjera frontend mund t'i përdorin, si dhe nga një metodë standarde e dërgimit dhe marrjes së të dhënave nëpërmjet mbështetësve dhe ngjarjeve.
Përbërja nga ana e serverit: Me këtë dizajn, pjesët e UI kombinohen në server, gjë që rezulton në një faqe të formuar plotësisht që dërgohet në anën e klientit, duke përshpejtuar ngarkimin.
Asambleja kryhet shpesh nga një shërbim i veçantë që ndodhet midis shfletuesit të internetit dhe serverëve të uebit. CDN është një shembull i shërbimit (rrjeti i shpërndarjes së përmbajtjes).
Ju mund të zgjidhni një ose një kombinim nga të dyja, në varësi të nevojave tuaja.
Modelet e komunikimit mikro frontend
Arkitektura mikro-frontend funksionon më mirë kur ka pak ose aspak ndërveprim midis komponentëve të ndryshëm. Mikro frontendët herë pas here duhet të flasin me njëri-tjetrin dhe të ndajnë informacione. Këtu janë disa modele të mundshme që mund të çojnë në këtë.
- Punëtorët e internetit: Një punonjës në internet është një mekanizëm që mundëson që përmbajtja e uebit të ekzekutojë JavaScript në sfond, pavarësisht nga skriptet e tjera dhe pa ndikuar në shpejtësinë e faqes. Një API unike e punës do të sigurohet për çdo aplikacion mikro. Ky përfitim është se puna që kërkon shumë kohë mund të bëhet në një fill tjetër, duke mundësuar që filli i UI të vazhdojë pa u ngadalësuar ose ndalur.
- Emitues i ngjarjeve: Në këtë rast, shumë komponentë komunikojnë me njëri-tjetrin duke dëgjuar dhe duke vepruar sipas çdo ndryshimi të gjendjes në komponentët në të cilët janë të regjistruar. Mikro frontendet e tjera që janë abonuar në atë ngjarje specifike përgjigjen kur një mikro frontend aktivizon atë ngjarje. Një emetues i ngjarjeve që është futur në çdo mikro-front e bën këtë të realizueshme.
- Thirrjet dhe mbështetësit: Në këtë seksion, ju përcaktoni një komponent prind dhe komponentë fëmijë. Komunikimi është i organizuar në një strukturë të ngjashme me pemën. Komponentët prindër përdorin mbështetës për të përcjellë të dhënat si funksione poshtë pemës përbërëse te komponentët fëmijë. Nga ana tjetër, fëmija mund të paralajmërojë në mënyrë efikase prindin kur ndodh ndonjë gjë në gjendjen e tyre duke iu përgjigjur thirrjeve. React përdor këtë mënyrë.
Të mirat e Micro frontend
Zhvillimi në ekipet autonome të shpejtë
Një ekip i pavarur mund të krijojë çdo pjesë të një aplikacioni në internet ose faqe interneti kur përdor një metodë mikro frontend.
Secili ekip është plotësisht autonom, që do të thotë se është përgjegjës për të gjithë ciklin e zhvillimit të komponentëve, nga konceptimi deri te publikimi dhe pas prodhimit.
Për më tepër, kjo nënkupton që ekipe të ndryshme mund të bashkëpunojnë pa probleme ndërsa punojnë njëkohësisht në të njëjtin projekt.
Prandaj, ciklet e lëshimit janë dukshëm më të shpejtë se sa do të ishin me monolitet e pjesës së përparme.
Bazat më të vogla të kodeve të mikro fronteve individuale çojnë në kod më të pastër
Fundet e përparme monolitike kanë baza kodesh të mëdha e të ngathëta që bëhen gjithnjë e më kaotike dhe sfiduese për t'u menaxhuar me kalimin e kohës.
Mikro frontendet e adresojnë këtë problem. Kodi burimor i çdo mikro frontend është më i menaxhueshëm pasi është më i vogël, më i thjeshtë dhe më kompakt.
Zgjidhja e përgjithshme e internetit përfiton nga kodi më i pastër si pasojë.
Stabilitet i përmirësuar i aplikacionit për shkak të një lidhjeje të lirshme
Një zgjidhje në internet rrallë mund të ndahet në pjesë krejtësisht të pavarura. Rrjedhimisht, mikro frontet flasin me njëri-tjetrin.
Megjithatë, çdo lidhje midis komponentëve është e rëndësishme pavarësisht lidhjes së lirë.
Dështimi i një komponenti ka pak ose aspak efekt në funksionimin e të gjithë komponentëve të tjerë, gjë që siguron stabilitet të zgjeruar të një zgjidhjeje në internet.
Testimi i veçorive individuale është bërë më i thjeshtë
Ky përfitim rezulton nga karakteristikat e mikro frontendeve. Bazuar në këtë dizajn arkitekturor, ana e klientit të një zgjidhje në internet është modulare dhe çdo modul është autonom.
Si rezultat, vlerësimi i një pjese të vogël të ndërfaqes së përdoruesit në vetvete është më i lehtë për një ekip sesa testimi i një monolit masiv.
Madhësia e zvogëluar e paketës çon në ngarkim më të shpejtë të faqes
Një nga shkaqet kryesore të vonesës së kohës së ngarkimit në sistemet monolitike të uebit të pasur me veçori është madhësia e një pakete JavaScript. Nga ana tjetër, një qasje mikro frontend e bën më të lehtë reduktimin e kohës së ngarkimit të faqes.
Një shfletues nuk duhet të shkarkojë kodin e panevojshëm në mënyrë të përsëritur pasi një faqe në internet përbëhet nga disa paketa të vogla. Si rezultat, performanca e faqes dhe koha e ngarkimit janë rritur.
Pavarësia e Teknologjisë
shumëfish kornizat e përparme mund të përdoret nga zhvilluesit për të krijuar një zgjidhje të vetme në internet me një arkitekturë mikro-frontend.
Meqenëse çdo komponent është autonom, ai mund të ndërtohet duke përdorur cilëndo teknologji që i përshtatet më mirë detyrave të ekipit.
Natyrisht, programuesit duhet të kenë kujdes kur zgjedhin kornizat për projektin e softuerit për të cilin janë në krye, dhe konsultimet me ekipet e tjera ende këshillohen fuqishëm.
Megjithatë, ka zero shanse që të detyroheni të përdorni një kornizë të trashëguar për kohëzgjatjen e jetëgjatësisë së aplikacionit.
Disavantazhet e Micro Frontend
Testimi kompleks i zgjidhjeve në ueb në tërësinë e tij
Testimi i moduleve të ndryshme të një zgjidhjeje në internet është i lehtë kur përdor një arkitekturë mikro-frontend. Megjithatë, ai ndryshon nga vlerësimi i një aplikacioni ueb në tërësi.
Verifikoni që të gjitha pjesët të funksionojnë siç është menduar përpara se të vazhdoni. Kjo mund të jetë e vështirë pasi mikro frontendet funksionojnë në mënyrë të pavarur dhe kanë procese të veçanta të dorëzimit.
Investime fillestare të shtrenjta
Zhvillimet mikro frontend zakonisht kërkojnë shpenzime të konsiderueshme financiare. Është e shtrenjtë për të mbledhur dhe mbajtur shumë ekipe të përparme.
Për më tepër, do t'ju duhet personel drejtues për të organizuar punën, për t'u siguruar që gjithçka të jetë e koordinuar dhe për të garantuar komunikim të shkëlqyer në ekip.
Kompleksiteti i zhvillimit dhe vendosjes
Procedurat e zhvillimit dhe vendosjes mund të bëhen më të ndërlikuara si rezultat i një dizajni mikro-frontend.
Një zgjidhje mund të jetë e mbushur me shumë komponentë nga ekipet e pavarura të zhvillimit që punojnë në të njëjtin projekt, për shembull, gjë që mund të shkaktojë probleme në fazën e vendosjes.
Asambleja e duhur e të gjitha moduleve dhe integrimi i tyre i qetë në skemën e përgjithshme nuk është gjithashtu gjithmonë i thjeshtë; kjo punë zakonisht kërkon një kuptim të plotë të të gjitha varësive.
Probleme me ruajtjen e koherencës në përvojën e përdoruesit
Mbajtja e një ndërfaqeje të qëndrueshme të përdoruesit është sfiduese kur ekipet punojnë veçmas në disa pjesë të softuerit.
Zgjidhja në internet duhet të ndahet nga të gjithë zhvilluesit e projektit. Përndryshe, mund të ketë shumë kontradikta përgjatë rrugës.
Përfundim
Micro frontends, një dizajn arkitekturor bashkëkohor, mund të përmirësojë shumë performancën e projekteve të zhvillimit të uebit të bazuar në mikroshërbime në shkallë të gjerë.
Ai u mundëson programuesve të ndajnë zgjidhjen e plotë në pjesë diskrete që mund të krijohen nga disa ekipe autonome. Përfitime të shumta vijnë nga kjo, duke përfshirë hapjen më të shpejtë të veçorive, testimin më të lehtë të moduleve individuale dhe përmirësimet më të pandërprera.
Por ka disa vështirësi edhe me mikro frontendet.
Testimi gjithëpërfshirës i një aplikacioni, për shembull, mund të jetë sfidues.
Për më tepër, për shkak se nevojitet një ekip i madh inxhinierësh dhe administratorësh, projektet mikro frontend janë shumë të shtrenjta.
Rrjedhimisht, përpara se të merrni një vendim, duhet të merrni parasysh të gjithë komponentët e çështjes suaj të biznesit.
Vladimír Čamaj
Disi nuk e kuptova se në çfarë parimi funksionon komunikimi midis komponentëve individualë në frontend. Nuk e kuptoj se si dëshironi të lidhni komponentët që janë krijuar në korniza të ndryshme. Nuk ka asgjë në artikull në lidhje me të. Sistemi i ngjarjeve dhe i dëgjuesve më duket si ferr në tokë. Si duhet ta imagjinojmë?