Taula de continguts[Amaga][Espectacle]
- Introducció a l'arquitectura micro-front-end
Avantatges de Micro frontend +-
- Desenvolupament en Equips Ràpidament Autònoms
- Bases de codi més petites de microfrontends individuals condueixen a un codi més net
- Millora de l'estabilitat de l'aplicació a causa d'un acoblament solt
- La prova de les funcions individuals es fa més senzilla
- La mida reduïda del paquet condueix a una càrrega de pàgina més ràpida
- Independència Tecnològica
- Conclusió
La idea dels microserveis ha guanyat molta atenció recentment i moltes empreses l'utilitzen per eliminar els backend grans i monolítics.
Seguir la mateixa ruta amb la interfície segueix sent un repte per a moltes empreses, encara que aquesta manera distribuïda de construir el costat del servidor de les aplicacions web sigui més o menys fiable en termes d'investigació i execució.
A causa de la seva estreta dependència, el monòlit del costat del client sol dificultar la integració de noves funcions, l'adopció de noves tecnologies i l'escalada de components individuals.
Aquests i altres reptes han fet que els desenvolupadors de frontend investiguin l'ús de microserveis.
Com a resultat, es va desenvolupar una nova estratègia arquitectònica coneguda com a micro frontend per crear la capa frontal de llocs web i aplicacions basades en web.
El terme es va utilitzar per primera vegada l'any 2016 i, des de llavors, ha cridat molta atenció per una bona causa.
Aquest article donarà una comprensió general de què són els micro frontends i els problemes que tracten. funciona, així com els pros i els contres.
Introducció a l'arquitectura micro-front-end
Un mètode contemporani de desenvolupament front-end anomenat arquitectura micro-frontend divideix a aplicació web en parts petites i independents.
Per a l'usuari final, aquestes parts semblen ser una unitat, encara que s'hagin construït de manera independent i després s'ajunten.
Amb la diferència que els micro frontends pertanyen al costat del client, no al costat del servidor, de les solucions en línia, la raó subjacent és idèntica a la dels microserveis.
Fer productes sofisticats basats en web té més sentit quan s'utilitza un enfocament de micro frontend.
Els micro frontends, a diferència d'un monòlit de front-end més convencional, permeten a molts equips col·laborar per separat en diversos projectes de programari.
Els programadors poden crear aplicacions web més ràpidament i amb una major escalabilitat i manteniment mitjançant aquest disseny arquitectònic.
Per dir-ho senzillament, cada micro frontend és només un tros de codi per a un component diferent de la pàgina web.
Aquestes funcions estan controlades per equips separats, cadascun dels quals s'especialitza en una indústria o objectiu determinat.
Arquitectura monolítica vs microserveis vs micro frontend
Penseu a traslladar-vos. Serà més fàcil per a tu organitzar-ho tot en una sèrie de petites caixes etiquetades per experts i reubicar cadascuna individualment o empaquetar tot el personal en una caixa enorme i transportar-lo a una nova ubicació?
La solució òbvia hi és.
Aquesta analogia compara les dues arquitectures d'aplicacions web diferents, monòlits i microserveis (també coneguts com a micro frontends).
Arquitectura monolítica
És possible que pugueu recordar els "bons vells temps" quan es va crear una aplicació completa com una entitat única i cohesionada. Aquest mètode s'anomena monòlit, que és un terme antic per a un bloc de pedra gran.
Això té sentit.
Els sistemes monolítics tenen elements interdependents. Per tant, si voleu modificar alguna cosa o afegir una característica nova, és possible que tot el sistema es trenqui.
Tot i que està obsolet, de vegades encara existeix. Sí, som conscients de la teva expressió actual.
La divisió conceptual de la base de codi en dos components diferents: el front-end (costat del client) i el backend (costat del servidor) - es va fer inevitable a mesura que es van desenvolupar noves tecnologies i els productes de programari es van complicar.
El mètode d'operació més popular és ara la separació de les preocupacions entre la capa de presentació amb la qual interactua un usuari final i tot el que té lloc en segon pla.
Necessita dos equips d'enginyeria de programari, amb l'equip frontal que construeix els components visuals i l'equip de fons que construeix els serveis web, la lògica empresarial, l'accés a les dades, les integracions, etc.
Tanmateix, malgrat aquesta separació, aquesta estratègia segueix sent monolítica per naturalesa.
El canvi principal és que ara tenim dos grans blocs de codi, el frontend i el backend, en lloc d'una aplicació enorme. Les arquitectures monolítices no han de ser terribles; tenen alguns avantatges, entre ells
- Desenvolupament senzill i ràpid per a aplicacions petites amb una única base de codi font i un disseny molt senzill;
- Les proves i la depuració són molt senzilles perquè tot el codi es troba en una sola ubicació, cosa que fa que sigui més fàcil per a un equip fer un seguiment del flux d'una sol·licitud i identificar errors;
- Al principi del desenvolupament d'una aplicació, les despeses són més barates, ja que no s'incorre en costos d'infraestructura ni en costos de desenvolupament fins que s'afegeixen noves funcions.
Els inconvenients d'aquesta estratègia es reflecteixen en
- Flexibilitat de desplegament restringida: els equips han d'esperar si només n'hi ha un grapat treballant en el projecte i es requereix un nou desplegament cada vegada que actualitzeu el codi;
- Adoptar noves tecnologies és un repte, ja que fer-ho requereix reescriure una part important, si no tot el projecte.
- Quan el nombre de desenvolupadors augmenta, un sistema de codi es torna estretament connectat, complicat i difícil de gestionar i comprendre.
- Problemes organitzatius: cada membre de l'equip ha d'utilitzar la mateixa versió de les biblioteques i informar de qualsevol canvi si molts equips estan treballant en un projecte monolític.
- Preocupacions amb l'escalabilitat: com que els components del projecte estan interconnectats, escalar-los per separat presenta dificultats que donen lloc a temps d'inactivitat significatius i despeses més altes.
- La complexa lògica del projecte podria ser difícil d'entendre per als nous membres de l'equip, sobretot si els enginyers que hi van treballar inicialment ja no estan empleats.
El desenvolupament de microserveis i els seus parents propers, i micro frontends, van abordar els problemes principals dels sistemes monolítics.
Arquitectura de microserveis
El mètode arquitectònic conegut com a microserveis permet la creació de molts components o serveis més petits, poc enllaçats i desplegables de manera independent, que formen un backend d'una aplicació.
Cada servei té la seva pròpia base de codi, canalitzacions CI/CD, procediments DevOps i processos per executar-los.
Podeu veure que l'equip de fons monolític es divideix en equips separats mirant la imatge de dalt.
Cadascun se centra individualment en un aspecte diferent de l'aplicació (com ara el servei del producte, el servei de cerca i el servei de pagament).
La comunicació entre els serveis es produeix mitjançant protocols establerts coneguts com a API, com ara el protocol API REST lleuger que utilitza patrons de sol·licitud-resposta sincrònics.
Una altra opció és utilitzar la comunicació asíncrona mitjançant programari com Kafka, que ofereix estructures i esdeveniments de comunicació de publicació/subscripció.
Els microserveis s'integren amb la interfície mitjançant un backend per al servei d'interfície (BFF) o una passarel·la API a través de la xarxa. BFF ofereix una API personalitzada per a cada client, mentre que les passarel·les API ofereixen un únic punt d'accés per a una col·lecció de microserveis.
Però fins i tot amb components de backend autònoms i tots els avantatges que proporcionen, la interfície segueix sent un monòlit.
Per tant, aquí és on els micro frontends són útils.
Arquitectura de micro frontends
De manera similar als microserveis, on diversos equips gestionen components poc enllaçats, l'arquitectura de micro frontend aplica el concepte al navegador.
Aquestes interfícies d'usuari d'aplicacions web segueixen aquesta estructura, que consta de components una mica autònoms.
Els equips també es creen segons les necessitats del client o els casos d'ús en lloc d'una experiència o tecnologia particulars.
En conseqüència, els equips estan involucrats en microserveis i projectes de micro frontend.
- tallats verticalment: com que també hi ha desenvolupadors d'interfície, experts en dades, enginyers de backend, enginyers de control de qualitat, etc. treballant en el mateix projecte, creen les seves característiques a partir del interfície d'usuari a bases de dades; i
- multifuncional: cada membre de l'equip aporta la seva experiència al grup.
Els equips també poden seleccionar la pila de tecnologia que millor s'adapti a la seva línia de negoci particular.
Un equip pot utilitzar React per programar el seu fragment. Un altre equip crea una nova versió d'Angular. Vue.js n'és un exemple.
Els micro frontends s'utilitzen conjuntament amb microserveis relacionats per resoldre problemes que solen tenir els equips de desenvolupament amb els monòlits. L'estratègia ofereix els següents avantatges.
- Llibertat tecnològica: els enginyers de front-end poden triar marcs alternatius de JavaScript, entorns d'execució i piles de tecnologia senceres en funció de les necessitats de l'empresa. A més de l'arquitectura obsoleta, es podria aplicar un marc nou.
- És possible un major grau de flexibilitat ja que cada micro frontend és autònom i es pot desenvolupar, provar, desplegar i actualitzar per separat. Com a resultat, si un equip està treballant en una funció i ha corregit un error i un altre equip ha d'afegir la seva pròpia funció, no cal que esperen que el primer equip completi la seva tasca.
- Equips i sistemes autònoms: cada equip de producte i, per tant, cada característica, pot funcionar amb poca dependència dels altres, cosa que li permet continuar funcionant fins i tot quan els components propers no estan disponibles.
- Bases de codi múltiples i més petites: cadascuna de les micro interfícies tindrà la seva pròpia base de codi més petita i més manejable. Menys persones es centraran en un component específic de la interfície d'usuari, simplificaran les revisions del codi i milloraran l'organització general.
- Escalat d'aplicacions senzill: un altre avantatge dels micro frontends és la possibilitat d'escalar cada funció individualment. A diferència dels monòlits, on s'ha d'escalar tot el programa cada vegada que s'afegeix una nova característica, això fa que tot el procés sigui més eficient tant en temps com en diners.
Com funciona el micro frontend?
Com hem dit anteriorment, els equips s'organitzen verticalment dins de l'arquitectura micro frontend, el que significa que estan separats per coneixements o finalitats del domini i són responsables de principi a fi d'un producte específic.
Pot tenir un o dos microserveis de fons, així com una interfície petita. Amb més detall, examinem les característiques d'aquest element visual, les interaccions amb altres components de la interfície d'usuari i la incorporació a la pàgina d'inici.
Un micro frontend pot ser
- una pàgina sencera (per exemple, una pàgina de detall del producte) o
- seccions de la pàgina que poden ser utilitzades per altres equips, com ara les capçaleres, els peus de pàgina i les barres de cerca.
Podeu dividir un lloc web gran en diversos tipus de pàgines i donar cada tipus a un personal específic per treballar.
Tanmateix, sovint apareixen diversos components en nombroses pàgines, com ara capçaleres, peus de pàgina, blocs de suggeriments, etc. Un bloc de suggeriments, per exemple, es pot incloure a una pàgina d'inici, una pàgina de detalls del producte o fins i tot a la pàgina de pagament.
En essència, els equips poden crear peces que altres equips poden utilitzar a les seves pàgines.
Els micro frontends, però, es poden desplegar per separat com a projectes diferents a diferència dels components reutilitzables.
Tot això sona fantàstic, però per crear una interfície unificada, les pàgines i els fragments s'han de combinar d'alguna manera.
Això requereix una integració de frontend, que es pot aconseguir mitjançant una varietat d'estratègies, com ara l'encaminament, la composició i la comunicació (vegeu el gràfic anterior).
Encaminament
Quan es requereix servei d'una pàgina controlada per un equip per accedir a una pàgina propietat d'un altre equip, l'encaminament és útil per a la integració a nivell de pàgina.
Cada micro frontend es gestiona com una aplicació d'una sola pàgina. Es poden utilitzar enllaços HTML senzills per proporcionar encaminament.
Un usuari pot obligar el navegador a descarregar el marcatge de destinació d'un servidor i substituir la pàgina actual per la nova fent clic als hiperenllaços.
L'intèrpret d'ordres de l'aplicació és el mínim d'HTML, CSS i JavaScript que alimenta una interfície d'usuari. Fins i tot si les dades de contingut sol·licitades al servidor encara estan esperant, l'usuari rep immediatament una pàgina estàtica. El shell de l'aplicació central serveix com a aplicació principal per a les aplicacions d'una sola pàgina creades pels diferents equips.
Independentment de la biblioteca o marc que s'utilitzi, els meta-marcs permeten la fusió de diverses pàgines en una sola.
Composition
La composició és el procés d'ordenar les peces per encaixar-les als espais adequats d'una pàgina. En la majoria dels casos, l'equip que desplega la pàgina no obté immediatament el contingut del fragment.
En comptes d'això, col·loca un marcador de posició o marcador on hauria d'estar el fragment a l'etiquetatge.
Mitjançant un procés de composició diferent, s'aconsegueix el muntatge final. La composició es pot dividir en dues categories bàsiques: del costat del client i del costat del servidor.
Composició del costat del client: el navegador web s'utilitza per crear i editar el marcatge HTML. Cada micro frontend té la capacitat de canviar i mostrar el seu marcatge per separat de la resta de la pàgina.
Els Web Components, per exemple, permeten dur a terme aquest tipus de construcció.
El pla és convertir cada fragment en un component web que es pugui instal·lar de manera independent com a fitxer a.js, després del qual les aplicacions poden carregar-los i representar-los als espais designats per a ells al disseny del tema.
Els components web depenen de l'API HTML i DOM, que poden utilitzar altres marcs d'interfície, així com un mètode estàndard per enviar i rebre dades mitjançant accessoris i esdeveniments.
Composició del costat del servidor: Amb aquest disseny, les peces de la interfície d'usuari es combinen al servidor, la qual cosa fa que una pàgina completament formada s'enviï al costat del client, accelerant la càrrega.
El muntatge es realitza sovint per un servei independent que es troba entre el navegador web i els servidors web. CDN és una instància del servei (xarxa de lliurament de contingut).
Podeu triar un o una combinació dels dos, segons les vostres necessitats.
Patrons de comunicació micro frontend
L'arquitectura micro-frontend funciona millor quan hi ha poca o cap interacció entre els diferents components. Els micro frontends de vegades necessiten parlar entre ells i compartir informació. Aquí hi ha alguns patrons potencials que poden conduir a això.
- Treballadors web: un treballador en línia és un mecanisme que permet que el contingut web executi JavaScript en segon pla, independentment d'altres scripts i sense afectar la velocitat de la pàgina. Es proporcionarà una API de treball única per a cada microaplicació. Aquest avantatge és que el treball que requereix molt de temps es pot fer en un fil diferent, la qual cosa permet que el fil de la interfície d'usuari continuï sense frenar-se ni aturar-se.
- Emissor d'esdeveniments: En aquest cas, molts components es comuniquen entre ells escoltant i actuant sobre qualsevol canvi d'estat dels components als quals estan subscrits. Altres micro frontends que s'han subscrit a aquest esdeveniment específic responen quan un micro frontend activa aquest esdeveniment. Un emissor d'esdeveniments que s'ha introduït a cada micro-frontend fa que això sigui factible.
- Devolució de trucades i accessoris: En aquesta secció, definiu un component pare i components secundaris. La comunicació s'organitza en una estructura en forma d'arbre. Els components pare utilitzen accessoris per transmetre les dades com a funcions per l'arbre de components als components secundaris. Al seu torn, el nen pot alertar de manera eficient els pares quan passa alguna cosa en el seu estat responent a les devolucions de trucada. React utilitza aquest mode.
Avantatges de Micro frontend
Desenvolupament en Equips Ràpidament Autònoms
Un equip independent pot crear cada part d'una aplicació web o lloc web quan s'utilitza un mètode de micro frontend.
Cada equip és completament autònom, és a dir, s'encarrega de tot el cicle de desenvolupament dels components, des de la concepció fins al llançament i la postproducció.
A més, implica que diversos equips poden col·laborar sense problemes mentre treballen simultàniament en el mateix projecte.
Per tant, els cicles d'alliberament són substancialment més ràpids del que serien amb monòlits frontals.
Bases de codi més petites de microfrontends individuals condueixen a un codi més net
Els front ends monolítics tenen bases de codi grans i difícils de manejar que es tornen cada cop més caòtiques i difícils de gestionar amb el temps.
Els micro frontends solucionen aquest problema. El codi font de cada micro frontend és més manejable, ja que és més petit, més senzill i més compacte.
La solució web global es beneficia d'un codi més net com a conseqüència.
Millora de l'estabilitat de l'aplicació a causa d'un acoblament solt
Una solució web poques vegades es pot dividir en peces completament independents. En conseqüència, els micro frontends parlen entre ells.
Tanmateix, cada enllaç entre els components és significatiu malgrat la connectivitat fluixa.
La fallada d'un component té poc o cap efecte en el funcionament de tots els altres components, cosa que proporciona l'estabilitat millorada d'una solució web.
La prova de les funcions individuals es fa més senzilla
Aquest benefici és el resultat de les característiques dels micro frontends. A partir d'aquest disseny arquitectònic, la part del client d'una solució web és modular i cada mòdul és autònom.
Com a resultat, avaluar una petita part de la interfície d'usuari per si mateixa és més fàcil de fer per a un equip que provar un monòlit massiu.
La mida reduïda del paquet condueix a una càrrega de pàgina més ràpida
Una de les causes principals del retard en els temps de càrrega en sistemes web monolítics rics en funcions és la mida d'un paquet de JavaScript. D'altra banda, un enfocament de micro frontend facilita la reducció del temps de càrrega de la pàgina.
Un navegador no ha de descarregar codi innecessari repetidament, ja que una pàgina web està formada per diversos paquets petits. Com a resultat, augmenta el rendiment de la pàgina i els temps de càrrega.
Independència Tecnològica
múltiple marcs de front-end pot ser utilitzat pels desenvolupadors per crear una única solució en línia amb una arquitectura micro-frontend.
Com que cada component és autònom, es pot construir amb la tecnologia que s'adapti millor a les tasques de l'equip.
Naturalment, els programadors haurien d'anar amb compte a l'hora de seleccionar marcs per al projecte de programari del qual s'encarreguen, i encara es recomana encaridament consultar amb altres equips.
Tanmateix, no hi ha possibilitats que us obliguin a utilitzar un marc heretat durant la vida útil de l'aplicació.
Contres de Micro Frontend
Prova de solucions web complexes en la seva totalitat
Provar els diferents mòduls d'una solució web és fàcil quan utilitza una arquitectura micro-frontend. Tanmateix, difereix d'avaluar una aplicació web en el seu conjunt.
Comproveu que totes les peces funcionin segons el previst abans de continuar. Això pot ser difícil, ja que els micro frontends funcionen de manera independent i tenen processos de lliurament separats.
Inversions inicials cares
Els desenvolupaments de micro frontend solen requerir despeses financeres substancials. És car muntar i mantenir molts equips de front-end.
A més, necessitareu personal directiu per organitzar la feina, assegurar-vos que tot estigui coordinat i garantir una excel·lent comunicació de l'equip.
La complexitat del desenvolupament i el desplegament
Els procediments de desenvolupament i desplegament poden complicar-se com a resultat d'un disseny de micro-frontend.
Una solució podria estar desordenada amb massa components per part dels equips de desenvolupament independents que treballin en el mateix projecte, per exemple, cosa que podria causar problemes en l'etapa de desplegament.
El muntatge correcte de tots els mòduls i la seva perfecta integració en l'esquema global tampoc no sempre és senzill; aquest treball requereix normalment una comprensió a fons de totes les dependències.
Problemes per mantenir la coherència en l'experiència d'usuari
Mantenir una interfície d'usuari coherent és un repte quan els equips treballen per separat en diverses parts del programari.
La solució web hauria de ser compartida per tots els desenvolupadors del projecte. En cas contrari, pot haver-hi moltes contradiccions al llarg del camí.
Conclusió
Els micro frontends, un disseny arquitectònic contemporani, poden millorar considerablement el rendiment dels projectes de desenvolupament web a gran escala basats en microserveis.
Permet als programadors dividir la solució completa en parts discretes que poden ser creades per diversos equips autònoms. D'això se'n deriven nombrosos avantatges, com ara un desplegament de funcions més ràpid, proves més fàcils de mòduls individuals i actualitzacions més fluides.
Però també hi ha algunes dificultats amb els micro frontends.
Les proves exhaustives d'una aplicació, per exemple, poden ser un repte.
A més, com que es necessita un gran equip d'enginyers i administradors, els projectes de micro frontend són molt cars.
En conseqüència, abans de prendre una decisió, heu de tenir en compte tots els components del vostre cas de negoci.
Vladimír Čamaj
D'alguna manera no entenia amb quin principi funciona la comunicació entre components individuals a la interfície. No entenc com voleu connectar components que es creen en diferents marcs. No hi ha res a l'article al respecte. El sistema d'esdeveniments i oients em sembla un infern a la terra. Com ens ho hem d'imaginar?