Monorepo vs Micro-Frontend: la Matrice che Nessuno Scrive
I micro-frontend risolvono problemi organizzativi, non tecnici. La "enterprise tax" è reale: ecco quando conviene davvero pagarla.
“Monorepo o micro-frontend?” è la domanda sbagliata, ma la senti ripetere in ogni retrospettiva architetturale.
Non sono la stessa decisione, e confonderle costa caro.
Il monorepo è una strategia di repository e sviluppo. Il micro-frontend è un’architettura runtime. Puoi avere un monorepo con un solo bundle, o un monorepo che orchestra dieci micro-frontend indipendenti. I micro-frontend non sono un upgrade morale rispetto al monolite: sono uno strumento di scaling con una tassa misurabile, e molti team la pagano prima di averne davvero bisogno.
Questa è la matrice decisionale che di solito nessuno scrive prima di adottarli.
Due Assi Diversi, Spesso Confusi
Monorepo e micro-frontend rispondono a domande diverse.
- Il Monorepo risponde a: “Come organizziamo il codice e la collaborazione tra i team?” È una scelta sul repository, non sul runtime dell’applicazione.
- Il Micro-Frontend risponde a: “Come isoliamo il deploy e il runtime di parti diverse dell’interfaccia?” È una scelta architetturale che ha un costo in bundle size, orchestrazione e complessità operativa.
- La Combinazione più Comune: Un monorepo che ospita più micro-frontend, spesso con Module o Native Federation, per avere il meglio di entrambi gli assi quando serve davvero.
Strategic Insight: Se stai scegliendo tra monorepo e micro-frontend come fossero alternative, hai già sbagliato la domanda.
Il Segnale che Conta Davvero: il Platform Team
La letteratura di settore converge su un punto: i micro-frontend senza un team platform dedicato tendono a derivare.
- Chi Possiede la Shell: Senza un team responsabile dell’orchestrazione, ogni micro-frontend finisce per reinventare le proprie convenzioni di routing, styling e comunicazione.
- Chi Garantisce la Coerenza Cross-Team: L’isolamento del deploy è un vantaggio solo se qualcuno mantiene coerenti le interfacce condivise tra le parti isolate.
- Chi Paga il Debito di Orchestrazione: Federazione dei moduli, versioning delle dipendenze condivise e contratti tra runtime diversi hanno bisogno di un proprietario esplicito, non di una responsabilità diffusa.
Trade-off Reality: Il 66% delle organizzazioni riporta scalabilità migliorata dopo aver adottato i micro-frontend, ma non ogni team ne ha bisogno: chi li adotta prematuramente paga l’enterprise tax senza il beneficio corrispondente.
Cosa Include davvero l’Enterprise Tax
Il costo dei micro-frontend non è nel pattern in sé, ma in tutto ciò che serve a sostenerlo.
- Bundle Duplicati: Ogni micro-frontend porta spesso la propria copia di dipendenze condivise, aumentando il peso complessivo scaricato dal client.
- Complessità di Debug Cross-Runtime: Un errore che attraversa i confini tra micro-frontend diversi è più difficile da tracciare di un errore in un’unica applicazione.
- Governance del Contratto tra Team: Le interfacce condivise tra micro-frontend richiedono lo stesso rigore di un’API pubblica, con lo stesso costo di manutenzione.
Matrice: Quando il Monorepo Basta, Quando Serve il Micro-Frontend
| Scenario | Monorepo (Monolite Modulare) | Micro-Frontend |
|---|---|---|
| Team Singolo o Piccolo | Sufficiente, zero overhead runtime | Tassa ingiustificata |
| Team Multipli, Deploy Coordinato | Sufficiente con confini interni | Overhead non necessario |
| Team Multipli, Release Indipendenti | Diventa un collo di bottiglia | Giustificato, se esiste un platform team |
| Stack Tecnologici Eterogenei | Non praticabile senza compromessi | Unico modo per farli coesistere in produzione |
I micro-frontend non risolvono problemi tecnici: risolvono problemi organizzativi, e vanno pagati solo quando quel problema esiste davvero.
Conclusione: la Domanda da Farsi Prima
Prima di scegliere tra monorepo e micro-frontend, guarda ai confini che hai già definito nella tua Architettura React Scalabile: se quei confini non esistono nemmeno dentro un singolo repository, aggiungere isolamento runtime non risolverà la mancanza di disciplina, la renderà solo più costosa da diagnosticare.
Le stesse alternative più leggere, come le Server Islands di Astro, meritano una valutazione onesta prima di pagare la tassa completa dei micro-frontend.
Non stai scegliendo un’architettura migliore. Stai scegliendo quale complessità sei disposto a pagare, e a chi la stai delegando.