Published On: Giugno 1, 2021

AUTORI

Martino Zito
Director @Bip xTech

Francesco Cioffi
Senior Solutions
Architect @Bip xTech

The Micro Frontend style of architecture design do for the frontend of an application what microservices do for the backend, breaking monolithic structures into smaller components that can then be assembled on a single page.

In un contesto tecnologico in cui lo stile architetturale dei micro-servizi (MSA[1]) si afferma con forza consentendo la scomposizione degli artefatti di backend, ci si chiede se lo stesso approccio possa essere adottato anche per i componenti di frontend.

Nel presente articolo ripercorriamo rapidamente un po’ di storia per poi concentrarci sulla sfida che i micro frontend auspicano di traguardare. Vediamo quale è lo stato dell’arte, e proviamo a fare un’ipotesi sulle possibili evoluzioni che ci aspettiamo nel prossimo futuro.

Infine, raccontiamo perché vale la pena di percorrere questa scelta e qual è l’approccio che stiamo adottando per supportare i nostri clienti che desiderano adottare questo paradigma.

1  Un po’ di storia

Nella “preistoria” il frontend era un monolite; tutte le funzionalità, sia che esse fossero server-side o client-side, risiedevano all’interno dello stesso artefatto software. Nello specifico le logiche di backend e quelle di front-end erano fortemente accoppiate, di norma, con un rendering delle componenti grafiche lato server.

La prima scomposizione avvenne con l’approccio a livelli, in gergo “layer” che scorporò le componenti grafiche dalle logiche in esecuzione lato server. Da quel momento gli artefatti si dividono e si affermano le Single Page Application (SPA).

Il termine Micro Frontend compare in letteratura verso la fine del 2016 mutuando sia il nome che gli obiettivi dello stile architetturale a micro-servizi. L’idea è quella di trovare un modo per rendere modulare anche il frontend suddividendolo in componenti funzionali autoconsistenti, che definiamo micro, per superare uno dei problemi più sentiti durante la fase di realizzazione e manutenzione ossia la gestione di una codebase unica.

Un cambio di paradigma avviene nei due anni successivi, quando prende piede l’approccio “Backend For Frontend” (BFF). La componente di backend a supporto del frontend viene scomposta in artefatti (logici o fisici) che insieme forniscono il set completo di funzionalità richieste dal client. I gruppi di lavoro, pertanto, possono lavorare ad un sottoinsieme di funzionalità applicative parallelamente. Anche relativamente alla parte client è possibile scomporre il frontend in moduli con una suddivisione basata su pagine e/o funzionalità, ciascuna delle quali è di proprietà end-to-end di un singolo gruppo di lavoro. Sebbene così scomposta la parte client rimane comunque un monolite.

Per superare i limiti del client monolitico, comincia ad affermarsi l’idea del Web Component. L’idea è quella di sfruttare lo standard introdotto dal W3C chiamato Custom Elements che permette di dotare il browser di elementi DOM custom codificati tramite Javascript. L’idea è di creare degli oggetti che non hanno come unica finalità la rappresentazione informativa, bensì di sfruttarli per un’applicazione più estensiva nell’ambito dei micro frontend.

Al giorno d’oggi sono nate parecchie iniziative in merito all’uso dei micro frontend, specie mediante l’applicazione dei Web ComponentIKEA impiega i micro frontend sullo store online, Spotify li usa per l’applicazione desktop. Zalando è a capo del Project Mosaic che raggruppa servizi e librerie utili per i micro frontend.

2 Punti di debolezza dell’approccio tradizionale

In un contesto di sviluppo, manutenzione o migrazione di un software le sfide che ci si trova ad affrontare sono spesso legate al time-to-market, ed alla manutenibilità degli artefatti; se da un lato, per quanto riguarda il backoffice, il problema si mitiga con l’introduzione dello stile architetturale a micro-servizi, per il frontend i problemi da affrontare sono principalmente i seguenti:

  1. È possibile suddividere un’applicazione in moduli ma la codebase rimane sempre la stessa per cui i team che lavorano contemporaneamente agli artefatti di frontend devono spendere parte del loro tempo a coordinarsi.
  2. I tempi di compilazione crescono man mano che le righe di codice aumentano. Anche ottimizzando, ogni modifica o integrazione richiede la ricompilazione dell’intero artefatto.
  3. Quando si interviene su un modulo per adeguare l’applicativo è necessario rilasciare l’intero artefatto. La modifica non è mai davvero isolata dal resto del contesto applicativo con un significativo rischio di regressioni.
  4. Il rilascio del frontend, che sia per l’intervento su un modulo o per un refactoring dell’intera applicazione, richiede la gestione dell’intero ciclo di rilascio con i conseguenti disservizi sull’intera applicazione.

Di fatto, abbiamo in parte vanificato l’effetto positivo introdotto dai micro-servizi, in termini di Time to Deliver (TTD) e Time to Market (TTM).

3 Le sfide tecnologiche

In base a quanto detto, è chiaro che è utile isolare gli artefatti, vediamo quali sono le principali sfide che ci si trova ad affrontare sui componenti di frontend.

Una volta effettuato il “taglio” in moduli indipendenti ed autonomi (aka micro app) è indispensabile un contenitore (applicazione shell) in grado di raggruppare, mettere in comunicazione ed armonizzare le varie micro app.

Gli elementi messi a disposizione dalle micro app sono innestati all’interno dell’applicazione shell. Questa deve essere in grado di accogliere dinamicamente le micro app, “componendo” il frontend nel suo insieme. Ogni micro app è aggiornabile indipendentemente dalla shell.

La shell deve garantire la comunicazione fra i componenti. Un componente dialoga tramite eventi e proprietà. È pertanto onere del contenitore l’orchestrazione dei componenti che accoglie in modo coerente rispetto alle interfacce dichiarate.

Infine, ci si deve preoccupare dell’aspetto dell’applicazione. Quando il browser carica un componente, in assenza di direttive, gli assegna un determinato aspetto. Quando si implementa un Web Component dobbiamo tener conto di questi principi:

  • il componente deve avere un comportamento di definito, ossia in assenza di direttive deve presentarsi con delle caratteristiche di default;
  • il componente non deve mai influenzare il comportamento del contenitore che lo ingloba;
  • il componente deve consentire al contenitore di personalizzare il proprio comportamento.

Le considerazioni appena elencate portano ad un maggior impegno realizzativo e ad una maggior cura in termini di disegno.

4 Perché scegliere i Micro Frontend

Nonostante le sfide appena descritte, vediamo però quali sono i vantaggi per cui conviene perseguire con quest’approccio:

  • le micro app sono autonome poiché ognuna ha una sola responsabilità;
  • le micro app possono essere sviluppate in modo indipendente aumentando il parallelismo;
  • sottoinsiemi del frontend possono essere rilasciati in modo indipendente senza alcun impatto su altre parti del sistema;
  • Web Component diversi possono essere implementati in tecnologie differenti, ciò favorisce sia la promiscuità del team che l’adozione di framework più aggiornati senza impattare sui componenti già presenti;
  • Web Component sono riusabili anche in frontend diversi rispetto a quelli per cui sono stati progettati.

5 Dove siamo oggi

Lo scenario attuale di strumenti a supporto è abbastanza variegato ed in rapida evoluzione.

Esistono diversi framework nati con l’obiettivo di realizzare Web Component, ad esempio, il progetto Polymer che successivamente si è convertito nel progetto LitElement. Esiste il progetto OpenWC che ha l’obiettivo di supportare la comunità nella creazione e nella condivisione di Web Component open source dove troviamo una serie di librerie e componenti che abbracciano l’iniziativa. Purtroppo, parliamo di progetti disarmonici nell’implementazione.

Di recente sono comparse sul mercato alcune librerie (single-spapiral.iofrint.js) con l’obiettivo di mettere a disposizione strumenti utili agli sviluppatori, nella forma di framework di sviluppo, per l’implementazione di applicazioni basate sul concetto del Micro Frontend.

Esistono inoltre alcuni marketplace che hanno l’obiettivo di raccogliere Web Component in un unico posto, mettendoli a disposizione della community. In alcuni casi l’approccio è fortemente legato ad un singolo prodotto, vedi Vaadin, in altri, web-components.org, si trovano elementi fra i più disparati. Non essendoci linee guida o standard anche solo de-facto diventa complesso basare un’applicazione su Web Component abbassando l’investimento.

6 Una vista sul Mercato

ThoughtWorks, nel 2019, inserisce i micro frontend in Adopt nel Technology Radar. A maggio 2020 è annoverata tra i maggiori benefici la possibilità, per i gruppi di lavoro, di scalare nella fornitura di servizi distribuiti e di gestirli in modo indipendente. È citato l’articolo[2] (su martinfowler.com) che funge da riferimento per questa tecnica.

Allo stesso tempo, però, sempre su ThoughtWorks, troviamo, più o meno nello stesso periodo, ottobre 2020, in Hold, il termine micro frontend anarchy. Viene definita particolarmente preoccupante la tendenza di utilizzare questa architettura come scusante per mescolare una gamma di tecnologie, strumenti o framework concorrenti in una singola pagina, portando all’anarchia del micro frontend. Infatti, oggi giorno, non esiste uno standard affermato, né da parte della community né da player che possano imporre sul mercato uno standard-de-facto. C’è sicuramente molto fermento: fanno la loro comparsa sul mercato aziende che pubblicizzano il pattern; vengono rilasciate librerie a supporto degli sviluppatori che approcciano agli sviluppi seguendo la metodologia; sono proposti framework in grado di supportare lo sviluppo con le principali tecnologie utilizzate per i componenti di frontend.

Grandi multinazionali stanno approcciando questo paradigma per i propri prodotti online. IKEA, preferisce dividere un sistema verticalmente per creare sistemi autonomi con backend e frontend costruiti dallo stesso gruppo di sviluppatori. La chiave del successo è mantenere piccoli i team. Jeff Bezos definisce la “regola delle due pizze”: se una squadra è troppo numerosa per sfamarsi con due pizze, la squadra è semplicemente troppo numerosa. I micro frontend hanno consentito a DAZN di potenziare i team più piccoli che possono lavorare in modo indipendente. HelloFresh ha risolto i problemi di gestione della propria applicazione monolitica scomponendola, così ogni progetto ha la propria infrastruttura ed il proprio ambiente di sviluppo isolato.

Probabilmente nel breve termine ci sarà un nuovo framework che indirizzerà la risoluzione delle problematiche tipiche a cui si va incontro con questa scelta, ovvero qualche player influente di mercato approccerà al tema in modo strutturato per cui ne conseguirà uno standard.

7 Why Bip

In Bip xTech da metà del 2020 stiamo adottando l’approccio dei micro frontend nello sviluppo di alcune delle soluzioni enterprise.

Abbiamo avviato l’applicazione di questo paradigma dopo intense analisi di mercato ed attente riflessioni sul modo giusto di approcciare, dapprima da un punto di vista astratto, successivamente influenzati dai contesti di delivery reali. Manteniamo sempre la massima attenzione rispetto ai movimenti di mercato in modo da poterci adeguare ad esso e beneficiare delle tecniche e dei nuovi strumenti emergenti.

Dopo più di un anno dal rilascio in produzione di sistemi che beneficiano di questa tecnica, possiamo affermare che i vantaggi sono significativi. Da nostre stime interne, possiamo affermare di aver ridotto l’effort di sviluppo del 30% con un risparmio in termini di tempo e costi. Siamo nella condizione di poter scalare la delivery con i gruppi di lavoro in quanto le funzionalità sono ben perimetrare ed il codice che le supporta è autonomo ed indipendente. Le porzioni di sistema sono sufficientemente semplici e la rapidità di approccio ai singoli componenti è notevolmente incrementata così come le regressioni, ad ogni step di rilascio, sono fortemente diminuite. L’effort impiegato per il testing è diminuito del 30% ed il tempo di intervento, in seguito alle segnalazioni ricevute in AM è praticamente dimezzato. Infine, ma non ultimo in ordine di importanza, l’adozione dei micro frontend ci consente di migrare codice legacy in modo incrementale senza necessità di affrontare reingegnerizzazioni impattanti in un colpo solo.

Concludendo, restiamo vigili in attesa della svolta cercando di contribuire con la nostra esperienza sul campo.


Se sei interessato a saperne di più sulla nostra offerta o vuoi avere una conversazione con uno dei nostri esperti, invia un’e-mail a bipxtech@mail-bip.com con “Micro Frontends” come oggetto, e sarai contattato prontamente.


[1] https://bipxtech.ai/it/introduzione-ai-microservizi/

[2] https://martinfowler.com/articles/micro-frontends.html