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.
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.
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.
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:
UX-ul și stylingul fiecărui Micro Frontend trebuie să urmeze un standard impus de ownerul aplicației.
Se expun o listă de evaluatori pentru fiecare opțiune de implementare a unui Micro Frontend:
Feature Autonom: fiecare aplicație poate să fie întreținută și deployed independent, iar codul este rulat în izolare, pentru a fi o aplicație independentă.
Team Ownership: aplicație independentă cu code repository propriu, iar echipa deține controlul total al codebase-ului (pe verticală, inclusiv partea microservicii și repository) .
Tech Agnostic: fiecare echipă are puterea să aleagă tehnologia Micro Frontendului, fără să afecteze produsul final sau alte microservicii.
User Experience: UI-ul final trebuie să dea impresia că e un produs SPA, independent și robust, fără probleme de performanță, cu același styling și UX.
Value Driven: fiecare Micro Frontend ar trebui să ofere o singură funcționalitate bine definită.
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ă.
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:
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
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.
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:
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.
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 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.
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
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.
de Daniel Tatar
de Ovidiu Mățan
de Diana Oniga
de Mihai Talpoș
