Monorepo vs polyrepo

Come si suddivide il codice in repository sembra una decisione di basso livello, ma condiziona silenziosamente il modo in cui il team collabora, rilascia e ragiona sul sistema. Un monorepo raccoglie tutto in un unico repository; un polyrepo assegna a ogni servizio o applicazione il proprio. Nessuno dei due è universalmente corretto, e le opinioni più accese che si trovano online ignorano quasi sempre la fase reale e le dimensioni del team. Ecco come ragionarci con chiarezza.

Cosa offre un monorepo

Un monorepo raccoglie web app, app mobile, backend e librerie condivise sotto lo stesso tetto. I vantaggi sono concreti, specialmente per i team più piccoli:

• Modifiche atomiche. Si aggiorna un tipo condiviso e ogni consumatore viene aggiornato nella stessa pull request. Nessun coordinamento tra repository diversi.
• Un'unica fonte di verità per i tool. Una sola configurazione di lint, formattazione e CI, anziché configurazioni che divergono tra una dozzina di repository.
• Condivisione del codice senza attrito. I package TypeScript condivisi sono semplici import, non versioni pubblicate da aggiornare e reinstallare ovunque.
• Refactoring semplificato. È possibile trovare e correggere ogni chiamata a una funzione perché tutto è a portata di mano.

Tool come Turborepo e Nx rendono tutto questo praticabile, memorizzando nella cache i build ed eseguendo il lavoro solo per le parti effettivamente modificate.

Cosa costa un monorepo

I compromessi emergono con la crescita. I tempi di build e CI possono gonfiarsi senza una caching intelligente. Il controllo degli accessi è meno granulare: è più difficile dare a un collaboratore esterno accesso a un solo servizio senza esporgli l'intera codebase. E una configurazione ingenua ricostruisce e testa tutto a ogni modifica, rallentandosi rapidamente. Un buon tooling mitiga tutto questo, ma richiede un investimento deliberato.

Cosa offre un polyrepo

Repository separati assegnano a ogni servizio confini netti. Un team possiede il proprio repository dall'inizio alla fine, rilascia secondo i propri ritmi e non può accedere accidentalmente ai dettagli interni di un altro team. Il controllo degli accessi è naturalmente granulare, la CI di ogni repository è snella e veloce, e l'impatto di una modifica errata rimane circoscritto.

Il costo è il coordinamento. Una modifica che coinvolge più servizi si traduce in pull request multiple su repository diversi, che devono essere integrate nell'ordine corretto. Il codice condiviso deve essere pubblicato come package versionati, e il disallineamento tra versioni nei diversi repository diventa una fonte concreta di bug. Mantenere il tooling coerente su molti repository richiede uno sforzo continuativo.

Come decidere concretamente

La risposta onesta è che le dimensioni del team e il grado di accoppiamento contano più dell'ideologia:

1. Fase iniziale o team dedicato a un solo prodotto? Usate un monorepo. Il risparmio in coordinamento è enorme quando tutti toccano tutto, ed è il punto di partenza più semplice.
2. Molti team indipendenti con servizi genuinamente separati e cadenze di rilascio distinte? I confini del polyrepo riducono l'attrito e consentono ai team di muoversi in autonomia.
3. Una via di mezzo? Iniziate con un monorepo, e scorporate un servizio nel proprio repository solo quando la sua ownership e il suo ciclo di rilascio divergono davvero dal resto.

Il default pragmatico

Per la maggior parte delle startup con cui lavoriamo, un monorepo con una buona cache dei build è la scelta giusta. Si adatta al modo in cui lavorano i team piccoli — tutti nella stessa codebase, a rilasciare insieme — e rimanda il costo di coordinamento del polyrepo al momento in cui si avrà effettivamente una struttura del team che ne beneficia. Separare un servizio in seguito è sempre possibile; riunire repository separati è molto più doloroso.

Se state configurando una codebase attorno alla quale far crescere un team, parlateci.