Il problema del frontend che cresce troppo

Avete presente quel progetto che all'inizio era un piccolo prototipo agile, veloce, quasi magico? Poi arrivano le feature. Poi arrivano i nuovi requisiti. Poi il team passa da tre a trenta sviluppatori.

A un certo punto succede. Il codice diventa una palude. Cambiare un colore in una pagina di checkout rischia di rompere casualmente il modulo di login. Il monolite ha vinto, e voi siete diventati ostaggi della vostra stessa applicazione.

È qui che entra in gioco l'approccio dei micro front end.

L'idea è semplice: fare con l'interfaccia utente ciò che i microservizi hanno fatto con il backend anni fa. Invece di avere un unico, enorme progetto React o Angular, dividiamo l'app in pezzi più piccoli, indipendenti e autonomi.

Cos'è esattamente un Micro Front End?

Non è un framework. Non è una libreria che scaricate con npm. È una strategia organizzativa.

Immaginate la vostra dashboard come un puzzle. La sezione "Profilo Utente" è gestita dal Team A. Il "Carrello Acquisti" dal Team B. Le "Analitiche" dal Team C. Ogni team possiede il proprio pezzo di interfaccia, lo sviluppa in isolamento, lo testa e lo distribuisce senza dover chiedere il permesso a nessuno o attendere che l'intero sito venga compilato per dieci minuti.

Proprio così. Autonomia totale.

Questo significa che il Team A potrebbe usare React 18, mentre il Team B, magari per necessità legacy o preferenza tecnica, continua a usare Vue.js. Sembra un caos? In realtà, se gestito bene, è l'unico modo per non impazzire quando l'applicazione raggiunge dimensioni enterprise.

Come si mettono in pratica? Le strade possibili

Non esiste un unico modo di implementare i micro front end. Dipende da dove volete che avvenga l'integrazione.

L'approccio lato server (Server-Side Composition)

Qui il server decide quali pezzi inviare al browser. Strumenti come SSI (Server Side Includes) o Edge Side Includes permettono di assemblare la pagina prima che arrivi all'utente. È ottimo per le performance e per l'SEO, ma meno dinamico.

L'integrazione lato client

Questa è la via più battuta oggi. Esistono diverse tecniche:

  • Iframe: La soluzione vecchia scuola. Isolamento perfetto, ma un incubo per l'UX e la comunicazione tra i moduli.
  • JavaScript Frameworks: Usare un "shell" (un contenitore) che carica dinamicamente i micro frontend via script tag o moduli ES.
  • Web Components: Forse la strada più elegante. Creare componenti standardizzati che funzionano ovunque, indipendentemente dal framework usato all'interno.

Un dettaglio non da poco è l'uso di Module Federation (introdotta con Webpack 5). Ha cambiato le regole del gioco permettendo a diverse build di condividere codice a runtime senza dover reinstallare tutto.

I vantaggi che contano davvero

Se pensate che i micro front end servano solo per "usare framework diversi", siete fuori strada. Il vero valore è nel workflow.

Il primo vantaggio è il deploy indipendente. Se devo correggere un bug nel modulo dei pagamenti, non devo redeployare l'intero portale aziendale. Carico solo quel pezzo di codice. Rischio ridotto, velocità aumentata.

Poi c'è la scalabilità del team. Ogni squadra ha il proprio ciclo di vita, i propri sprint e le proprie responsabilità. Non ci sono più colli di bottiglia dove dieci persone devono toccare lo stesso file App.js creando conflitti di merge infiniti.

Meno coordinamento forzato, più velocità d'esecuzione.

Il lato oscuro: non è tutto oro

Sarebbe ingenuo dire che questa architettura sia la soluzione a ogni problema. Anzi, introduce complessità nuove e fastidiose.

Il rischio principale? Il peso della pagina. Se ogni micro frontend carica la propria copia di React, l'utente finale scaricherà megabyte di codice ridondante. La pagina diventerà lenta come un bradipo.

Poi c'è il problema dell'estetica. Come fate a garantire che il pulsante "Salva" del Team A sia identico a quello del Team B? Senza un Design System condiviso e rigoroso, l'interfaccia sembrerà un Frankenstein digitale, con colori e margini che cambiano ogni due clic.

Infine, c'è la complessità infrastrutturale. Gestire dieci pipeline di CI/CD è più difficile che gestirne una sola.

Quando ha senso fare questo salto?

Non usate i micro front end per un sito vetrina o per una startup con tre persone. Sarebbe come usare un rimorchio di un camion per trasportare una busta della spesa. È un overkill tecnico che vi rallenterebbe solo.

Passate a questa architettura quando:

  • Il team frontend è diventato troppo grande per coordinarsi in un unico repository.
  • Avete diverse aree del prodotto con cicli di rilascio differenti.
  • Volete migrare gradualmente da un vecchio framework a uno nuovo senza dover riscrivere tutto da zero (la cosiddetta Strangler Fig Pattern applicata al frontend).

Se vi trovate in queste condizioni, il passaggio non è più un'opzione, ma una necessità per sopravvivere.

Strategie per non fallire

Per rendere i micro front end sostenibili, concentratevi su tre pilastri.

Primo: Comunicazione minimale. I micro frontend devono essere il più possibile slegati tra loro. Se il modulo A ha bisogno di sapere costantemente cosa succede nel modulo B, avete creato un "monolito distribuito", che è il peggior scenario possibile. Usate eventi personalizzati o un semplice state management globale leggero.

Secondo: Governance condivisa. Decidete insieme le regole di base. Quale versione di TypeScript usare? Come gestire l'autenticazione? Queste decisioni devono essere centralizzate per evitare che ogni team faccia come gli pare.

Terzo: Automazione spinta. Senza test automatizzati e deploy continui, i micro front end diventano un incubo gestionale. L'automazione è il collante che tiene insieme i pezzi del puzzle.

In definitiva, l'architettura a micro front end sposta la complessità dal codice all'infrastruttura. È uno scambio consapevole: accettiamo di gestire una rete più complessa per liberare i team dalla paralisi del monolite.