INHOUDSOPGAWE[Versteek][Wys]
Die idee van mikrodienste het onlangs baie aandag gekry, en baie firmas gebruik dit om weg te doen met groot, monolitiese backends.
Om dieselfde roete met die frontend te gaan is steeds 'n uitdaging vir baie besighede, selfs al is hierdie verspreide manier om die bedienerkant van webtoepassings te bou min of meer betroubaar in terme van navorsing en uitvoering.
As gevolg van sy noue afhanklikheid, maak die kliënt-kant monoliet dit tipies moeilik om nuwe kenmerke te integreer, nuwe tegnologie aan te neem en individuele komponente te skaal.
Hierdie en ander uitdagings het frontend-ontwikkelaars aangespoor om ondersoek in te stel na die gebruik van mikrodienste.
Gevolglik is 'n splinternuwe argitektoniese strategie bekend as mikro-frontend ontwikkel vir die skep van die voorste laag van webwerwe en webgebaseerde toepassings.
Die term is die eerste keer in 2016 gebruik, en sedertdien het dit baie aandag vir 'n goeie doel gekry.
Hierdie artikel sal 'n algemene begrip gee van wat mikro-frontends is en die kwessies wat hulle aanspreek. dit werk, sowel as voor- en nadele.
Inleiding tot mikro front-end argitektuur
'n Kontemporêre metode van front-end ontwikkeling genoem mikro-frontend argitektuur verdeel a web aansoek in klein, onafhanklike dele.
Vir die eindgebruiker blyk hierdie dele een eenheid te wees, selfs al is hulle onafhanklik gebou en dan saamgevoeg.
Met die verskil dat mikro-frontends betrekking het op die kliëntkant, nie die bedienerkant nie, van aanlyn oplossings, is die rasionaal onderliggend daaraan identies aan dié van mikrodienste.
Die maak van gesofistikeerde webgebaseerde produkte maak die meeste sin wanneer 'n mikro-frontend-benadering gebruik word.
Mikro frontends, in teenstelling met 'n meer konvensionele front-end monoliet, stel baie spanne in staat om afsonderlik saam te werk aan verskeie sagtewareprojekte.
Programmeerders kan webtoepassings vinniger en met groter skaalbaarheid en onderhoubaarheid skep deur hierdie argitektoniese ontwerp te gebruik.
Om dit eenvoudig te stel, elke mikro-frontend is net 'n stukkie kode vir 'n duidelike komponent van die webblad.
Hierdie kenmerke word beheer deur afsonderlike spanne, wat elkeen in 'n sekere bedryf of doelwit spesialiseer.
Monolitiese vs mikrodienste vs mikro-frontend-argitektuur
Dink daaraan om te verhuis. Sal dit vir jou makliker wees om alles in 'n aantal klein, kundig benoemde boksies te organiseer en elkeen afsonderlik te hervestig of die hele personeel in een enorme boks op te pak en na 'n nuwe plek te vervoer?
Die ooglopende oplossing is daar.
Hierdie analogie vergelyk die twee verskillende webtoepassingsargitekture, monoliete en mikrodienste (ook bekend as mikro-frontends).
Monolitiese argitektuur
Jy kan dalk die "goeie ou dae" onthou toe 'n volledige aansoek as 'n enkele, samehangende entiteit geskep is. So 'n metode word 'n monoliet genoem, wat 'n ou term vir 'n groot klipblok is.
Dit maak sin.
Monolitiese sisteme het interafhanklike elemente. Daarom, as jy iets wil verander of 'n nuwe kenmerk wil byvoeg, is dit moontlik dat die hele stelsel kan breek.
Al is dit verouderd, bestaan dit soms nog. Ja, ons is bewus van jou huidige uitdrukking.
Die konseptuele verdeling van die kodebasis in twee verskillende komponente - voorkant (kliëntkant) en agterkant (bedienerkant) - het onvermydelik geword namate nuwe tegnologie ontwikkel en sagtewareprodukte ingewikkelder geraak het.
Die gewildste metode van operasie is nou die skeiding van bekommernisse tussen die aanbiedingslaag waarmee 'n eindgebruiker interaksie het en alles wat in die agtergrond plaasvind.
Dit benodig twee sagteware-ingenieurspanne, met die front-end-span wat die visuele komponente bou en die back-end-span wat die webdienste, besigheidslogika, datatoegang, integrasies, ens.
Ten spyte van hierdie skeiding bly hierdie strategie steeds van nature monolities.
Die belangrikste verandering is dat ons nou twee aansienlike blokke kode het - die voorkant en die agterkant - in plaas van een enorme toepassing. Monolitiese argitekture hoef nie vreeslik te wees nie; hulle het 'n paar voordele, insluitend
- Eenvoudige en vinnige ontwikkeling vir klein toepassings met 'n enkele bronkodebasis en 'n baie eenvoudige ontwerp;
- Toets en ontfouting is baie eenvoudig omdat alle kode op een plek is, wat dit makliker maak vir 'n span om 'n versoek se vloei op te spoor en foute te identifiseer;
- Vroeg in die ontwikkeling van 'n toepassing is uitgawes goedkoper aangesien nóg infrastruktuurkoste nóg ontwikkelingskoste aangegaan word totdat nuwe kenmerke bygevoeg word.
Die nadele van hierdie strategie word weerspieël in
- Beperkte ontplooiingsbuigsaamheid – spanne moet wag as daar net 'n handjievol van hulle is wat aan die projek werk en nuwe ontplooiing word vereis elke keer as jy die kode opdateer;
- Die aanneming van nuwe tegnologieë is uitdagend, aangesien dit die herskryf van 'n beduidende gedeelte, indien nie die hele projek, noodsaak nie.
- Wanneer die aantal ontwikkelaars toeneem, word 'n kodestelsel nou verbind, ingewikkeld en moeilik om te bestuur en te begryp.
- Organisatoriese kwessies – elke spanlid moet dieselfde weergawe van biblioteke gebruik en enige veranderinge rapporteer as baie spanne aan 'n monolitiese projek werk.
- Kommer oor skaalbaarheid – omdat die projek se komponente onderling verbind is, bied die skaal daarvan afsonderlik probleme wat aansienlike stilstand en hoër uitgawes tot gevolg het.
- Die projek se komplekse logika kan moeilik wees vir nuwe spanlede om te verstaan, veral as die ingenieurs wat oorspronklik daaraan gewerk het, nie meer in diens is nie.
Die ontwikkeling van mikrodienste en hul naasbestaandes, en mikro-frontends, het die primêre probleme met monolitiese stelsels aangespreek.
Mikrodienste argitektuur
Die argitektoniese metode bekend as mikrodienste maak voorsiening vir die skepping van baie los-gekoppelde en onafhanklik ontplooibare kleiner komponente, of dienste, wat 'n toepassing-backend vorm.
Elke diens het sy eie kodebasis, CI/CD-pyplyne, DevOps-prosedures en prosesse om dit uit te voer.
U kan sien dat die monolitiese backend-span in afsonderlike spanne verdeel word deur na die prent hierbo te kyk.
Elkeen fokus individueel op 'n ander aspek van die toepassing (soos die produkdiens, soekdiens en betaaldiens).
Kommunikasie tussen die dienste vind plaas deur gevestigde protokolle bekend as API's, soos die liggewig REST API-protokol wat sinchrone versoek-antwoord-patrone gebruik.
Nog 'n opsie is om asinchroniese kommunikasie te gebruik deur sagteware soos Kafka te gebruik, wat kommunikasiestrukture en -geleenthede vir publiseer/inteken bied.
Mikrodienste integreer met die frontend via 'n backend vir die frontend (BFF) diens of 'n API Gateway deur die netwerk. BFF bied 'n pasgemaakte API vir elke kliënt, terwyl API Gateways 'n enkele toegangspunt bied vir 'n versameling mikrodienste.
Maar selfs met outonome backend-komponente en al die voordele wat dit bied, is die frontend steeds 'n monoliet.
Daarom is dit waar mikro-frontends nuttig is.
Mikro frontend argitektuur
Soortgelyk aan mikrodienste, waar losgekoppelde komponente deur verskeie spanne bestuur word, pas die mikro-frontend-argitektuur die konsep op die blaaier toe.
Hierdie webtoepassingsgebruikerskoppelvlakke volg hierdie struktuur, wat uit ietwat outonome komponente bestaan.
Spanne word ook geskep op grond van kliëntbehoeftes of gebruiksgevalle eerder as spesifieke kundigheid of tegnologie.
Gevolglik is spanne betrokke by mikrodienste en mikro-frontend-projekte.
- vertikaal gesny — aangesien daar frontend-ontwikkelaars, data-kundiges, backend-ingenieurs, QA-ingenieurs, ens. ook aan dieselfde projek werk, skep hulle hul kenmerke uit die gebruikerskoppelvlak na databasisse; en
- kruisfunksioneel – elke spanlid dra hul kundigheid tot die groep by.
Spanne kan ook die tegnologiestapel kies wat die beste by hul spesifieke bedryf pas.
Een span kan React gebruik om sy fragment te programmeer. 'n Ander span skep 'n nuwe Angular-weergawe. Vue.js is een so 'n voorbeeld.
Mikro-frontends word saam met verwante mikrodienste gebruik om probleme wat ontwikkelingspanne tipies met monoliete het, aan te spreek. Die strategie bied die volgende voordele.
- Tegnologievryheid: Frontend-ingenieurs kan alternatiewe JavaScript-raamwerke, looptydomgewings en hele tegnologiestapels kies, afhangende van die behoeftes van die onderneming. Bo en behalwe die verouderde argitektuur, kan 'n vars raamwerk toegepas word.
- 'n Groter mate van buigsaamheid is moontlik aangesien elke mikro-frontend selfstandig is en afsonderlik ontwikkel, getoets, ontplooi en opgegradeer kan word. As gevolg hiervan, as een span aan 'n kenmerk werk en 'n foutoplossing gedruk het, en 'n ander span moet sy eie kenmerk byvoeg, hoef hulle nie te wag vir die eerste span om hul taak te voltooi nie.
- Outonome spanne en stelsels: Elke produkspan, en gevolglik elke kenmerk, kan funksioneer met min afhanklikheid van ander, wat dit in staat stel om aan te hou werk selfs wanneer die nabygeleë komponente nie beskikbaar is nie.
- Veelvuldige, kleiner kodebasisse: Elkeen van die mikro-frontends sal sy eie, meer hanteerbare, kleiner kodebasis hê. Minder mense sal op 'n spesifieke UI-komponent fokus, koderesensies vereenvoudig en algehele organisasie verbeter.
- Eenvoudige toepassingskaal: Nog 'n voordeel van mikro-frontends is die vermoë om elke kenmerk individueel te skaal. In teenstelling met monoliete, waar die hele program afgeskaal moet word elke keer as 'n nuwe kenmerk bygevoeg word, maak dit die hele proses meer doeltreffend in terme van tyd en geld.
Hoe werk mikro-frontend?
Soos ons voorheen gesê het, is spanne vertikaal georganiseer binne die mikro-frontend-argitektuur, wat beteken dat hulle deur domeinkennis of -doel geskei word en van begin tot einde verantwoordelik is vir 'n spesifieke produk.
Dit kan een of twee backend-mikrodienste sowel as 'n klein frontend hê. Kom ons ondersoek hierdie visuele element se kenmerke, interaksies met ander UI-komponente en inkorporering in die tuisblad in meer besonderhede.
'n Mikro-frontend kan wees
- 'n hele bladsy (bv. 'n produkbesonderhedebladsy) of
- afdelings van die bladsy wat deur ander spanne gebruik kan word, soos die koptekste, voettekste en soekbalke.
U kan 'n groot webwerf in verskeie bladsysoorte verdeel en elke tipe aan 'n spesifieke personeel gee om aan te werk.
Verskeie komponente kom egter gereeld op talle bladsye voor, soos koptekste, voettekste, voorstelblokke, ens. 'n Voorstelblok kan byvoorbeeld op 'n tuisblad, 'n produkbesonderhedebladsy of selfs die betaalbladsy ingesluit word.
In wese kan spanne stukke skep wat ander spanne op hul bladsye kan gebruik.
Die mikro-frontends kan egter afsonderlik as verskillende projekte ontplooi word, in teenstelling met die herbruikbare komponente.
Dit alles klink fantasties, maar om 'n verenigde koppelvlak te skep, moet bladsye en fragmente op een of ander manier gekombineer word.
Dit vereis frontend-integrasie, wat bewerkstellig kan word deur 'n verskeidenheid strategieë, insluitend roetering, samestelling en kommunikasie (sien die grafiek hierbo).
Routing
Wanneer diens vanaf 'n bladsy wat deur een span beheer word vereis word om toegang te verkry tot 'n bladsy wat deur 'n ander span besit word, is roetering nuttig vir bladsyvlak-integrasie.
Elke mikro-voorkant word as 'n enkelbladsy-toepassing hanteer. Eenvoudige HTML-skakels kan gebruik word om roetering te verskaf.
'n Gebruiker kan die blaaier verplig om die teikenopmerk van 'n bediener af te laai en die huidige bladsy met die nuwe een te vervang deur op hiperskakels te klik.
Die app-dop is die minimum van HTML, CSS en JavaScript wat 'n UI aandryf. Selfs as die inhouddata wat van die bediener aangevra is, nog wag, ontvang die gebruiker dadelik 'n statiese vertoonde bladsy. Die sentrale toepassingsdop dien as 'n ouertoepassing vir die enkelbladsytoepassings wat deur die verskillende spanne geskep is.
Ongeag die biblioteek of raamwerk wat gebruik word, meta-raamwerke maak die samesmelting van verskeie bladsye in 'n enkele een moontlik.
samestelling
Komposisie is die proses om die stukke te rangskik om hulle in die toepaslike spasies op 'n bladsy te pas. In die meeste gevalle haal die span wat die bladsy ontplooi nie dadelik die inhoud van die fragment nie.
In plaas daarvan plaas dit 'n plekhouer of merker waar die fragment in die opmaak behoort te wees.
Deur 'n ander samestellingsproses te gebruik, word die finale samestelling voltooi. Die samestelling kan in twee basiese kategorieë verdeel word: kliëntkant en bedienerkant.
Kliënt-kant samestelling: Die webblaaier word gebruik om HTML-opmerk te skep en te wysig. Elke mikro-voorkant het die vermoë om sy opmaak te verander en afsonderlik van die res van die bladsy te wys.
Webkomponente, byvoorbeeld, laat jou toe om hierdie tipe konstruksie uit te voer.
Die plan is om elke fragment te omskep in 'n webkomponent wat onafhanklik as 'n a.js-lêer geïnstalleer kan word, waarna die toepassings dit kan laai en weergee in die spasies wat vir hulle in die tema-uitleg aangewys is.
Webkomponente is afhanklik van die HTML- en DOM-API, wat ander frontend-raamwerke kan gebruik, sowel as 'n standaardmetode om data via rekwisiete en gebeurtenisse te stuur en te ontvang.
Bedienerkant samestelling: Met hierdie ontwerp word die UI-stukke op die bediener gekombineer, wat daartoe lei dat 'n volledig gevormde bladsy na die kliëntkant gestuur word, wat die laai versnel.
Die samestelling word dikwels uitgevoer deur 'n aparte diens wat tussen die webblaaier en die webbedieners sit. CDN is een voorbeeld van die diens (inhoudafleweringsnetwerk).
Jy kan een of 'n kombinasie van die twee kies, afhangende van jou behoeftes.
Mikro frontend kommunikasie patrone
Die mikro-frontend-argitektuur werk die beste wanneer daar min tot geen interaksie tussen die verskillende komponente is nie. Mikro-frontends moet soms met mekaar praat en inligting deel. Hier is 'n paar potensiële patrone wat daartoe kan lei.
- Webwerkers: 'n Aanlyn werker is 'n meganisme wat webinhoud in staat stel om JavaScript op die agtergrond te laat loop, onafhanklik van ander skrifte, en sonder om die spoed van die bladsy te beïnvloed. 'n Unieke werker-API sal vir elke mikro-toepassing voorsien word. Hierdie voordeel is dat tydrowende werk in 'n ander draad gedoen kan word, wat die UI-draad in staat stel om voort te gaan sonder om vertraag of gestop te word.
- Gebeurtenisuitstraler: In hierdie geval kommunikeer baie komponente met mekaar deur te luister na en op te tree op enige toestandsveranderinge in die komponente waarop hulle ingeteken is. Ander mikro-frontends wat op daardie spesifieke gebeurtenis ingeteken het, reageer wanneer 'n mikro-frontend daardie gebeurtenis afvuur. 'n Gebeurtenisuitstraler wat in elke mikro-frontend ingestel is, maak dit haalbaar.
- Terugbelle en rekwisiete: In hierdie afdeling, definieer jy 'n ouer komponent en kind komponente. Die kommunikasie is georganiseer in 'n boomagtige struktuur. Ouerkomponente gebruik rekwisiete om die data as funksies in die komponentboom na die kindkomponente oor te dra. Op sy beurt kan die kind die ouer doeltreffend waarsku wanneer enigiets in hul toestand voorkom deur op terugbeloproepe te reageer. React gebruik hierdie modus.
Voordele van mikro-frontend
Ontwikkeling in vinnig outonome spanne
'n Onafhanklike span kan elke deel van 'n webtoepassing of webwerf skep wanneer 'n mikro-frontend-metode gebruik word.
Elke span is heeltemal outonoom, wat beteken dat dit in beheer is van die hele komponent-ontwikkelingsiklus, van konsepsie tot vrystelling en na-produksie.
Daarbenewens impliseer dit dat verskeie spanne naatloos kan saamwerk terwyl hulle gelyktydig aan dieselfde projek werk.
Daarom is vrystellingsiklusse aansienlik vinniger as wat dit met front-end monoliete sou wees.
Kleiner kodebasisse van individuele mikrofronte lei tot skoner kode
Monolitiese voorkante het groot, onhandelbare kodebasisse wat mettertyd toenemend chaoties en uitdagend word om te bestuur.
Mikro frontends spreek hierdie probleem aan. Elke mikro-frontend se bronkode is meer hanteerbaar aangesien dit kleiner, eenvoudiger en meer kompak is.
Die algehele weboplossing baat as gevolg daarvan by skoner kode.
Verbeterde toepassingstabiliteit as gevolg van 'n los koppeling
'n Weboplossing kan selde ooit in heeltemal onafhanklike stukke verdeel word. Gevolglik praat mikro-frontends wel met mekaar.
Elke skakel tussen die komponente is egter beduidend ten spyte van die los verbinding.
Die mislukking van een komponent het min tot geen effek op die werking van al die ander komponente nie, wat die verbeterde stabiliteit van 'n weboplossing bied.
Toets individuele kenmerke is makliker gemaak
Hierdie voordeel spruit uit die kenmerke van mikro-frontends. Gebaseer op hierdie argitektoniese ontwerp, is 'n weboplossing se kliëntkant modulêr en elke module is outonoom.
As gevolg hiervan is dit makliker vir 'n span om 'n klein gedeelte van die gebruikerskoppelvlak op sigself te evalueer as om 'n massiewe monoliet te toets.
Verminderde bondelgrootte lei tot vinniger bladsylaai
Een van die primêre oorsake van vertraagde laaitye in kenmerkryke monolitiese webstelsels is die grootte van 'n JavaScript-bundel. Aan die ander kant maak 'n mikro-frontend-benadering dit makliker om bladsylaaityd te verminder.
'n Blaaier hoef nie onnodige kode herhaaldelik af te laai nie, aangesien 'n webblad uit verskeie klein bondels bestaan. As gevolg hiervan word bladsyprestasie en laaitye verhoog.
Tegnologie Onafhanklikheid
veelvuldige front-end raamwerke kan deur ontwikkelaars gebruik word om 'n enkele aanlyn oplossing met 'n mikro-frontend argitektuur te skep.
Aangesien elke komponent outonoom is, kan dit saamgestel word met behulp van watter tegnologie ook al die beste by die span se take pas.
Programmeerders moet natuurlik versigtig wees wanneer hulle raamwerke kies vir die sagtewareprojek waaroor hulle in beheer is, en konsultasies met ander spanne word steeds sterk aangeraai.
Daar is egter geen kans dat jy gedwing sal word om 'n erfenisraamwerk vir die duur van die toepassing se leeftyd te gebruik nie.
Nadele van Micro Frontend
Komplekse weboplossingstoetsing in sy geheel
Dit is maklik om die verskillende modules van 'n weboplossing te toets as dit 'n mikro-frontend-argitektuur gebruik. Dit verskil egter van die evaluering van 'n webtoepassing as geheel.
Verifieer dat alle dele funksioneer soos bedoel voordat u voortgaan. Dit kan moeilik wees aangesien mikro-frontends onafhanklik funksioneer en afsonderlike afleweringsprosesse het.
Duur aanvanklike beleggings
Mikro-frontend-ontwikkelings vereis gewoonlik aansienlike finansiële uitgawes. Dit is duur om baie voorste spanne saam te stel en by te hou.
Daarbenewens het jy bestuurspersoneel nodig om die werk te organiseer, seker te maak dat alles gekoördineer is en uitstekende spankommunikasie te waarborg.
Die kompleksiteit van ontwikkeling en ontplooiing
Die ontwikkeling en ontplooiing prosedures kan meer ingewikkeld raak as gevolg van 'n mikro-frontend ontwerp.
'n Oplossing kan byvoorbeeld deur onafhanklike ontwikkelingspanne wat aan dieselfde projek werk met te veel komponente deurmekaar wees, wat probleme in die ontplooiingstadium kan veroorsaak.
Die regte samestelling van al die modules en hul gladde integrasie in die algehele skema is ook nie altyd eenvoudig nie; hierdie werk vereis gewoonlik 'n deeglike begrip van al die afhanklikhede.
Probleme met die handhawing van samehang in die gebruikerservaring
Die handhawing van 'n konsekwente gebruikerskoppelvlak is uitdagend wanneer spanne afsonderlik aan verskeie dele van die sagteware werk.
Die weboplossing moet deur al die projek se ontwikkelaars gedeel word. Andersins kan daar baie teenstrydighede langs die pad wees.
Gevolgtrekking
Mikro-frontends, 'n kontemporêre argitektoniese ontwerp, kan die werkverrigting van grootskaalse mikrodiens-gebaseerde webontwikkelingsprojekte aansienlik verbeter.
Dit stel programmeerders in staat om die volledige oplossing in afsonderlike dele te verdeel wat deur verskeie outonome spanne geskep kan word. Daar is talle voordele hieruit, insluitend vinniger funksie-uitrol, makliker toetsing van individuele modules en meer naatlose opgraderings.
Maar daar is ook 'n paar probleme met mikro-frontends.
'n Toepassing se omvattende toetsing kan byvoorbeeld uitdagend wees.
Daarbenewens, omdat 'n groot span ingenieurs en administrateurs nodig is, is mikro-frontend-projekte baie duur.
Gevolglik, voordat jy tot 'n besluit kom, moet jy alle komponente van jou sakesaak in ag neem.
Vladimír Čamaj
Op een of ander manier het ek nie verstaan op watter beginsel die kommunikasie tussen individuele komponente op die frontend werk nie. Ek verstaan nie hoe jy komponente wat in verskillende raamwerke geskep is, wil koppel nie. Daar is niks in die artikel daaroor nie. Die stelsel van gebeure en luisteraars lyk vir my na hel op aarde. Hoe moet ons ons dit voorstel?