Architettura a micro frontend

I micro frontend estendono il concetto dei microservizi all'interfaccia utente: una grande app web viene suddivisa in parti sviluppate, testate e distribuite in modo indipendente. Ogni parte è gestita da un team distinto e le parti vengono combinate a runtime in un'unica esperienza.

Una singola app Angular enorme (un "frontend monolitico") vincola ogni team a un'unica cadenza di rilascio, un'unica build e un'unica distribuzione. Con la crescita dei team, tutto questo rallenta il lavoro. I micro frontend permettono ai team di distribuire secondo i propri tempi.

La proprietà fondamentale è la distribuibilità indipendente: il team del checkout può distribuire un nuovo flusso di checkout senza ricostruire o ridistribuire il catalogo prodotti. Ogni remote è un artefatto separato, gestito dalla propria pipeline.

Dal punto di vista architetturale esiste un host (shell) che carica uno o più remote. La shell gestisce il routing di primo livello e il layout; i remote forniscono aree funzionali caricate on demand.

I remote possono essere combinati al momento della build, sul server (SSI/edge) oppure a runtime nel browser. La composizione a runtime con Module Federation è la più comune in Angular, perché preserva la distribuzione indipendente.

Module Federation consente a un'app compilata di esporre moduli che un'altra app compilata carica via HTTP a runtime, condividendo le librerie comuni per evitare duplicazioni. È il motore alla base della maggior parte dei micro frontend Angular.

Ogni micro frontend dovrebbe corrispondere a un dominio aziendale ben definito, come catalogo, checkout o account. Confini di dominio chiari riducono al minimo l'accoppiamento tra team, che è lo scopo principale. Le esigenze condivise, come autenticazione e design system, diventano contratti espliciti.

I micro frontend aggiungono una complessità concreta: versioni non allineate tra i remote, dipendenze duplicate se configurati in modo errato, debugging più difficile tra i confini e problemi di caricamento a runtime. Li adotti solo quando le dimensioni dei team giustificano questo sovraccarico.

Per un team piccolo o per un singolo prodotto, un monolite ben strutturato con route caricate in modo lazy è più semplice e veloce. I micro frontend sono vantaggiosi quando più team devono distribuire in modo indipendente sulla stessa app.

Per evitare un'interfaccia Frankenstein, i team condividono una libreria di design system e gli stili globali. La coerenza è un contratto deliberato, non una coincidenza, perché ogni remote viene compilato separatamente.

I remote Angular devono condividere a runtime una sola copia del framework Angular; caricare due versioni di Angular compromette la dependency injection e aumenta le dimensioni del bundle. Strumenti come Native Federation gestiscono questa condivisione al posto Suo.

Qual è il principale vantaggio dei micro frontend?

I micro frontend suddividono una grande app in remote distribuibili in modo indipendente e caricati da una shell host, associandoli a domini aziendali. La composizione a runtime tramite Module Federation è lo standard per Angular, che deve condividere una sola copia del framework. Risolvono l'accoppiamento tra team, ma aggiungono costi operativi concreti.