Nel mondo dello sviluppo web, si sta diffondendo sempre di più la tecnica dello sviluppo a microfrontend. Si tratta di uno dei concetti più innovativi del mondo frontend dai tempi dell’introduzione delle Single Page Application (SPA). Esso però, sostanzialmente, riprende e riadatta tecniche già utilizzate ma mai definite in maniera organica e ora in parte dimenticate.
L’idea di base è mutuata dalla tecnica dei microservizi, già ampiamente diffusa nel mondo dello sviluppo backend, in cui un’applicazione altro non è che un insieme di servizi. Tali servizi hanno la caratteristica di essere per nulla o debolmente accoppiati (cioè senza o con una quantità minimale di punti di interazione tra di loro, come ad esempio un database o una cache), e di granularità più fine possibile, vale a dire che la funzionalità dev’essere minimale. Amazon stabilisce la regola informale per cui, per non eccedere con il numero dei membri del team di sviluppo di un microservizio, esso si possa nutrire con al più due pizze (americane, quindi di grandi dimensioni).
I vantaggi di questo approccio sono evidenti:
- i team di sviluppo dei microservizi sono il più possibile indipendenti e non ostacolano il lavoro di altri gruppi con i propri problemi o ritardi;
- il crash di un singolo microservizio non compromette la stabilità degli altri microservizi;
- conseguentemente, la stabilità dello stesso gateway ne guadagna;
- la superficie di attacco dell’applicazione è frammentata tra i vari microservizi, isolando il problema di eventuali hack malevoli.
Lo sviluppo frontend oggi
Nello sviluppo frontend si è invece assistito a un’evoluzione delle pratiche di sviluppo in senso sostanzialmente opposto. L’avvento delle Single Page Application – che siano sviluppate in React, in Angular o in qualsivoglia framework moderno – ha implicato che le applicazioni web fossero gestite interamente da un unico applicativo monolite, con un livello di accoppiamento elevato tra le funzionalità. Questo ha a sua volta comportato dei vantaggi:
- facilità di creare un look&feel omogeneo dell’applicazione;
- gestione delle rotte del browser come parte integrante dello stato dell’applicazione;
- download una tantum degli asset dell’applicazione;
- trasferimento dati ridotto al solo aggiornamento dello stato.
Tuttavia, lo sviluppo frontend non si è sempre esplicitato in applicazioni monolitiche. C’è stato un periodo in cui pagine e applicazioni web erano usualmente composte da uno scheletro principale e da un insieme di widget isolati e affiancati spesso in maniera disomogenea. Ma è da qui che parte il concetto di microfrontend.
I concetti di base
L’idea di partenza di un’architettura a microfrontend consiste nella suddivisione dell’interfaccia complessiva in sotto-funzionalità interattive il più possibile indipendenti.
Una volta individuate le sottointerfacce, si procede allo sviluppo di ciascuna di esse – che diverrà così un microfrontend – parallelamente tra team differenti, e del layer di gestione e coordinamento dei vari microfrontend. Questo è un approccio che ricalca quello dell’architettura a microservizi, dove il layer orchestratore fa le veci del gateway di backend.
Ogni microfrontend consisterà quindi di una piccola applicazione rappresentante un’unica feature, caricata e visualizzata dal layer orchestratore insieme alle altre, e indipendente da esse. La realizzazione userà i comuni metodi di sviluppo frontend, basati su un framework moderno (Angular, Vue, React, …) e librerie di manipolazione dati e viste.
I vantaggi immediati sono i seguenti, simili a quelli già noti per i microservizi:
- maggiore libertà dei team di scelta del proprio stack tecnologico;
- minor impegno necessario per il coordinamento tra team e più tempo dedicato allo sviluppo e alla cura del prodotto;
- sviluppi delle singole parti più spediti perché indipendenti tra loro.
Del resto, sono subito evidenti anche i compromessi da accettare per l’uso dei microfrontend:
- ogni microfrontend avrà come dipendenze le proprie librerie e framework necessari per il funzionamento: è dunque possibile che l’utente debba scaricare, analizzare ed eseguire più versioni dello stesso pacchetto;
- le linee guida di design UI e UX devono essere chiare e ben definite anzitempo, pena il rischio di avere una cacofonia di esperienze utente;
- il layer orchestratore deve avere un’interfaccia chiara e concordata con i team di sviluppo.
Realizzare l’isolamento
Uno dei punti fondamentali del concetto dei microfrontend, al pari di quello dei microservizi, è il disaccoppiamento tra gli stessi. Questo significa che ogni parte dell’interfaccia dovrà avere influenza su un proprio ramo del DOM della pagina, avrà stili che agiscono solo e soltanto su esso, e dovrà definire un namespace nello spazio delle variabili globali da cui non dovrà uscire.
Il metodo più semplice per realizzare ciò è l’uso di elementi <iframe>, che però pagano lo scotto di essere pesanti dal punto di vista del caricamento e dell’occupazione di memoria. Inoltre relegano a un’area visuale ben definita il microfrontend, senza possibilità di uscirne facendo a meno del layer orchestratore.
Un altro valido approccio consiste nell’impacchettamento del microfrontend in un custom element, possibilmente con incapsulamento degli stili. Un framework come Angular supporta questa procedura nativamente.
Negli altri casi, la versione pacchettizzata dei microfrontend dovrà essere tenuta isolata prestando cura a ogni aspetto di possibile conflitto tra le varie parti.
Microfrontend: perché sì
A questo punto è chiaro che un’architettura a microfrontend ha come obiettivo la developer experience (DX), al fine di ottimizzare la frequenza degli aggiornamenti e l’isolamento dei problemi, sacrificando in parte i tempi di startup iniziale e impegno di memoria e processore.
Questo è un approccio che ha come sfera ideale le applicazioni web di larga scala usate in ambito business, ma non esclude anche altre piattaforme web di ampio utilizzo dove il “peso” della parte puramente applicativa è sovrastato da altri asset (ad esempio la fruizione di contenuti multimediali).
Microfrontend: perché no
Come accennato, l’utilizzo di un’architettura a microfrontend comporta dei compromessi a livello di impegno di risorse. Tali risvolti si possono mitigare con un’infrastruttura di sistema che consenta la condivisione di pacchetti e librerie comuni, tramite uso di una Content Delivery Network (CDN) e protocolli di trasferimento più moderni come HTTP/2 e il prossimo HTTP/3. C’è da ricordare che consentire più libertà ai team nel scegliere il proprio stack tecnologico non significa lasciare carta bianca: è perfettamente legittimo circoscrivere l’ambito delle scelte a determinati framework e librerie comuni, in modo da creare anche delle codebase omogenee e più gestibili tramite code review.
Tuttavia, anche con questi accorgimenti l’uso dei microfrontend potrebbe non essere la soluzione migliore. Ad esempio:
- se l’ambito del progetto è gestibile da un unico team;
- se è possibile avere una buona parallelizzazione degli sviluppi delle varie parti dell’applicazione tra i vari team;
- se, per via del target di utenza e di connettività, si debba puntare a un uso di risorse del client minimale.
La scelta migliore
Deve essere innanzitutto chiaro che i microfrontend non sono una tecnica che consente di fare cose nuove, ma solo di affrontare i progetti con un nuovo approccio. Infatti, gli stessi risultati si possono raggiungere con uno sviluppo monolitico, ma questo comporta coordinamento, affiatamento e capacità di comunicazione tra team, nonché una diffusione delle capacità tecniche frutto di parecchi anni di esperienza.
Quando anche solo uno di questi punti viene a mancare si va incontro a normali problemi di coordinamento tra team che l’approccio dei microfrontend cerca di aggirare. Ad esempio, questa metodologia può essere valida nel caso di feature sviluppate da diversi team di fornitori esterni, che non sempre possono contare su una comunicazione fra loro ottimale.
Scelte simili di sviluppo sono sempre state intraprese, ma senza un approccio formale e una definizione precisa del metodo impiegato. Di conseguenza non si era finora arrivati a curare le varie problematiche di sviluppo sopra elencate.
Oggi la definizione del concetto di microfrontend aiuta a puntare l’attenzione proprio su questi aspetti metodologici.
