ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 144
Numărul 143 Numărul 142 Numărul 141 Numărul 140 Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 92
Abonament PDF

Microservicii peste tot, dar cum rămâne cu Micro Frontends?

Bogdan Nădișan
Digital Technology Architect @ Accenture



PROGRAMARE


Micro web service ca pattern arhitectural a apărut în industria IT în anul 2005, folosit de Peter Rogers, într-o conferință despre cloud computing. Apoi, a fost folosit la un eveniment de arhitectură software în anul 2011, sub termenul de "Microservices". Termenul de "Microservices" a fost preluat și folosit ca mod de descriere a unui stil de arhitectură pe care mai multe persoane îl testau în acel moment. La început, conceptul a fost aplicat, în general, pentru proiecte noi, greenfield, însă azi, conceptul de microservicii a intrat deja în lumea enterprise, arhitectura fiind direcționată, în principal, și cu o schimbare de deployment, în mare parte înspre lumea Cloud.

Pornind de la premisa că deja știm ce înseamnă conceptul de microservicii, în acest articol, încerc să exprim o părere personală despre cum ar trebui să arate un microserviciu, cu o atenție sporită în partea de UI, în contextul Web Developmentului.

Definiție

Pentru început, ar trebui să fixăm definiția conceptului. Micro Fronted-ul extinde conceptul de microservicii, însă în lumea frontendului.

Figura 1. Arhitectura bazată pe microservicii, fără impact pe frontend

Arhitectura bazată pe Micro Frontenduri este o abordare de a scrie aplicații finale de frontend , compuse din mai multe aplicații mai mici. Așadar, în loc să scriem o aplicație web mare, monolitică, vom crea o aplicație mare compusă dintr-o colecție de aplicații mai mici, care sunt self-contained și care pot să fie implementate și livrate independent.

Provocarea

Până acum, scopul programatorilor din lumea Web era să scrie aplicații SPA (Single Page Applications) bogate în funcționalitate, interactive și responsive. În general, rezultatul devine un monolit complex și greu de întreținut, la care lucrează zeci de programatori, toți folosind același technology stack.

Într-o arhitectură bazată pe microservicii, în general, rezultatul este următorul:

Așa cum se vede în figura de mai sus, chiar dacă serviciile urmăresc patternul arhitectural bazat pe microservicii, acesta în general nu se reflectă și la nivel de frontend.

Practic, toată echipa de development de frontend trebuie să folosească același technology stack, care, în lumea JavaScript, devine învechit cu fiecare zi care trece. Într-un monolit scris în HTML5/JavaScript, switchul de tehnologie e foarte complex, în principal din cauza dependențelor între librăriile care se folosesc.

În continuare, vom vedea mai multe moduri prin care layerul de Frontend se poate împărți în mai multe micro frontenduri.

Soluția

Așadar, avem un frontend scris ca un monolit, dezvoltat de o echipă mare de programatori. Scopul este să dăm controlul înapoi echipei de development a fiecărui microserviciu, în așa fel încât, să poată să își aleagă tehnologia cea mai bună pentru a rezolva o anumită cerință funcțională, chiar și la nivel de frontend.

Practic, transformarea arhitecturală ar trebui să ne ducă la următoarea arhitectură:

Figura 2. Transformare de la o arhitectură bazată pe microservicii, la o arhitectură bazată pe microservicii, verticală, inclusiv Micro Frontend.

Există mai multe principii pe care echipele independente de dezvoltare de UI trebuie să le îndeplinească. Două exemple sunt următoarele:

  1. UX-ul și stylingul fiecărui Micro Frontend trebuie să urmeze un standard impus de ownerul aplicației.

  2. De asemenea, fiecare Micro Frontend trebuie să aibă SSO implementat (single sign on), preferabil prin folosirea unui standard de autentificare (OAUTH2 sau SAML).

Se expun o listă de evaluatori pentru fiecare opțiune de implementare a unui Micro Frontend:

Acești evaluatori vor fi expuși colorat mai jos, pentru fiecare abordare în parte: verde însemnând că rezultatul evaluării este pozitiv, iar roșu, că evaluarea este negativă.

Runtime diferit

Fiecare Micro Frontend rulează în runtime-ul său propriu, în izolare, fiind ,de fapt, o aplicație independentă. Acesta se poate îndeplini în două moduri:

Micro Apps

Prin acest concept, utilizatorul va vedea o listă de aplicații care pot să fie afișate ca SPA. Practic, se va afișa o listă de URL-uri ce te trimite la o colecție de SPA-uri, fiecare SPA oferind acces la o singură capabilitate, în izolare. Interacțiunea între aceste SPA-uri se va face prin extinderea query stringului pasat ca URL, sau prin interacțiune de date la nivel de microservicii.

Figura 3. Colecție de Micro Apps

IFrame

O altă tehnologie web prin care se poate realiza o arhitectură bazată pe Micro Frontenduri se referă la IFrame-uri. Prin această abordare, avantajul cel mai mare este ca toate capabilitățile pot să fie afișate pe același UI, iar interacțiunile se pot face la nivel de client, prin procesul de interacțiune între IFrame-uri (obiecte serializabile).

Pentru genul acesta de soluție, există frameworkuri care ajută la orchestrarea aplicațiilor scrise ca IFrame-uri. Practic, dacă fiecare IFrame ar afișa niște metadate care prezintă structurile de date cu care ele lucrează și API-urile pe care le expun, atunci s-ar putea crea UI-uri noi sau chiar scenarii de business noi, doar prin configurare.

Același Runtime

Aplicația rulează în același proces, folosind aceeași memorie. Fapt ce implică o serie de constrângeri tehnice. Există trei moduri de a implementa această abordare, expuse mai jos:

Web components

Această soluție se referă la modul în care se pot folosi API-urile platformei în care aplicația rulează, mai exact vom folosi Browserul ca API. Acesta oferă posibilitatea de a crea HTML tag-uri noi, customizate, refolosibile și încapsulate. Pe scurt, Web Components sunt o colecție de componente ce conțin elemente HTML custom, Shadow DOM și HTML imports.

Cu această soluție, resursele și memoria sunt împărțite între Micro Fontenduri.

Chiar dacă scorul acestei tehnologii este pozitiv, părerea mea este că acest standard mai trebuie să evolueze pentru a îndeplini toate cerințele tehnice ale industriei IT. Există diferențe de suport între browsere, unele oferă mai multe capabilități, altele mai puține.

Framework Based Components

Marii producători de frameworkuri de web (Angular, React, Vue.js) au văzut nevoia programatorilor și a businessului de a modulariza componentele de UI. Mai ales, din cauza faptului că dezvoltarea funcționalității native de Web Components este lentă.

Figura 6. Micro Frontend cu același Technology Stack

Așadar, prin folosirea aceluiași technology stack între UI-uri se pot scrie aplicații cu team ownership diferit, folosind frameworkuri care acceptă să creeze UI-uri modulare.

Transclusion

Transclusion se referă la faptul că aplicația e formată ca o colecție de micro frontenduri care este construită la nivel de server, practic un agregator de fișiere JavaScript și HTML.

Această operație de Transclusion se poate executa atât pe Server, cât și pe Client.

Sugestie de Framework pentru integrare/orchestrare

Lista de frameworkuri de pe internet care e specializată pe implementarea de Micro Frontenduri în lumea web e destul de limitată: la o căutare simplă numărul de rezultate e destul de mic, iar documentația acestor frameworkuri nu e foarte completă.

Merită menționat frameworkul de Web numit SCION Microfrontend Platform. Este un framework în dezvoltare, însă cu principii solide și cu un API ușor de folosit. Pe deasupra este și open source. Frameworkul este scris complet în TypeScript și permite integrarea oricărui conținut web. Vine cu funcționalități solide de transmitere a datelor între Micro Frontenduri, într-un mod cross-origin. Datele se pot transmite fie Request-Response, fie P2P, fie Topic-Based. Conținutul web este încapsulat într-un Web Component Responsive ce încapsulează IFrame-ul în care rulează SPA-ul. Web Component-ul rezolvă și o serie de provocări care vin cu tehnologia IFrame-ului.

Un exemplu de UI în care sunt expuse 5 Micro Frontenduri (4 unul lângă celălalt, iar în prima instanță, se demonstrează și posibilitatea de a face un nested Micro Frontend) cum exemplifică poza de pe pagina următoare.

Figura 7. SCION Framework - IFrame

URL demo: https://scion-microfrontend-platform-app-1.now.sh/\#/testing-app/browser-outlets;count=3

URL NPM: https://www.npmjs.com/package/\@scion/microfrontend-platform

Concluzie

Pe măsura ce aplicațiile de frontend continuă să devină tot mai complexe de-a lungul anilor, vedem o nevoie tot mai mare de arhitecturi mai scalabile. Trebuie să fim capabili să tragem limite clare care să stabilească nivelurile corecte de cuplare și coeziune între componente. Pe lângă aceasta, trebuie să fim capabili să scalăm livrarea de programe în echipe independente și autonome.

Prin implementarea arhitecturii bazate pe Micro Frontenduri, putem să ajutăm atât aplicațiile enterprise cât și aplicațiile mai mici să își redobândească puterea de a scala developmentul între mai multe echipe, folosind tehnologii cât mai noi, cu un impact izolat asupra produsului final.

LANSAREA NUMĂRULUI 144

Modern Agile

joi, 20 iunie, ora 18:00

sediul msg systems Romania

Facebook Meetup StreamEvent YouTube

NUMĂRUL 143 - Software Craftsmanship

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • P3 group
  • Ing Hubs
  • Colors in projects