Quando un frontend diventa troppo grande per un team, i micro-frontend offrono una strada da seguire.
L'architettura micro-frontend applica i principi dei microservizi al frontend: moduli frontend sviluppati, testati e distribuiti in modo indipendente che si compongono in un'unica applicazione unificata. Secondo il ThoughtWorks Technology Radar 2025, i micro-frontend sono passati dallo stato di prova allo stato di adozione, con il 34% delle organizzazioni con 50 o più sviluppatori frontend che utilizzano o pilotano attivamente l'approccio. Aziende come Spotify, IKEA e DAZN hanno condiviso pubblicamente le loro storie di successo sul micro-frontend, dimostrando che il modello funziona su scala significativa.
In x13apps implementiamo un'architettura micro-frontend per clienti con basi di codice di grandi dimensioni e più team di sviluppo. Ecco quando e come adottare questo modello in modo efficace.
Quando i micro-frontend hanno senso
I micro-frontend non sono adatti a tutti i progetti: aggiungono costi significativi. Aggiungono valore quando: più team devono lavorare sulla stessa applicazione in modo indipendente senza sovrapporsi a vicenda, parti diverse dell'applicazione hanno requisiti tecnologici o cadenze di aggiornamento diverse, la base di codice è diventata troppo grande per essere gestita in modo efficace da un singolo team o è necessario migrare in modo incrementale da un frontend legacy senza una riscrittura completa. Se hai meno di tre team frontend, le spese generali probabilmente superano i vantaggi.
I sintomi comuni che segnalano i micro-frontend potrebbero essere d'aiuto: colli di bottiglia nella distribuzione in cui una modifica del team blocca tutte le distribuzioni, uniscono conflitti tra team che lavorano nella stessa base di codice, incapacità di adottare nuovi framework perché il monolite ti lega alla vecchia tecnologia e l'onboarding degli sviluppatori richiede settimane a causa delle dimensioni della base di codice. Secondo ThoughtWorks, i team che utilizzano micro-frontend segnalano una consegna delle funzionalità più rapida del 40% e una riduzione del 60% del sovraccarico di coordinamento tra team rispetto agli approcci frontend monolitici.
Modelli di implementazione e scelte tecniche
Esistono tre modelli di composizione principali. La composizione in fase di compilazione tramite Module Federation (Webpack 5) condivide il codice in fase di compilazione, consentendo dipendenze condivise ma richiedendo build coordinate tra i team. La composizione lato server (Edge Side Include, Tailor di Zalando) assembla le pagine sul server, fornendo il tempo di interazione più rapido ma richiedendo un'infrastruttura server. La composizione lato client (single-spa, qiankun o Module Federation in fase di runtime) offre la massima flessibilità ma può aumentare le dimensioni e la complessità del bundle JavaScript.
La Module Federation, introdotta in Webpack 5 e ora supportata da Rspack e Vite tramite plugin, è diventata l'approccio dominante. Consente ai micro-frontend di condividere le dipendenze in fase di runtime, riducendo la dimensione totale del bundle evitando librerie duplicate. Ogni micro-frontend è un processo di creazione separato che produce il proprio bundle, distribuito in modo indipendente. L'applicazione host (shell) li carica e li orchestra. Questo approccio consente a team realmente indipendenti di avere cicli di rilascio e scelte tecnologiche propri.
Governance e standard condivisi per il successo
Senza governance, i micro-frontend creano incoerenze che peggiorano l’esperienza dell’utente. Stabilire standard condivisi: un sistema di progettazione con componenti condivisi (tramite Storybook o strumenti simili), test dei contratti API tra i team per prevenire interruzioni dell'integrazione, convenzioni di routing coerenti, modelli di gestione degli errori standardizzati e budget prestazionali per micro-frontend. Strumenti come Bit, Nx o Turborepo aiutano a gestire le dipendenze condivise e a creare orchestrazione su più progetti frontend.
Definire confini di proprietà chiari in linea con i domini aziendali piuttosto che con i livelli tecnici. Ogni micro-frontend dovrebbe corrispondere a un dominio aziendale (catalogo prodotti, checkout, profilo utente, ricerca) piuttosto che a problemi tecnici. Questo allineamento, chiamato suddivisione verticale, consente a ciascun team di comprendere il dominio aziendale di sua proprietà e di fornire valore completo all'utente in modo indipendente. Noi di x13apps progettiamo soluzioni frontend che si adattano alla struttura della tua azienda e del tuo team. Per ulteriori informazioni sulle decisioni relative all'architettura del frontend, leggi il nostroConfronto tra framework JavaScript.