I vantaggi tecnici del multi-repo sono piuttosto limitati: repository più piccoli, tempi di clonazione più rapidi, possibilmente prestazioni migliorate su CI, ma nulla che dovrebbe avere un impatto reale sulle scale antropiche. Potrebbero esserci vantaggi organizzativi a seconda di come avviene la comunicazione e il processo tra i membri del team della tua applicazione.
Lo svantaggio tecnico di un multi-repo verrà notato immediatamente: non è possibile modificare i file su due repository con un singolo commit, non è possibile unire le modifiche su due file in repository diversi in un singolo commit, non è possibile ripristinare cambia tra due file in un singolo commit, ecc.
Se il tuo client e server sono strettamente accoppiati, non essere in grado di apportare modifiche su entrambi i lati in un attimo ti costringerà a sprecare un grande sforzo per eseguire le attività di sviluppo quotidiane. Spedizione di una nuova funzionalità? Divertiti a creare due rami di funzionalità, eseguendo due distribuzioni di staging, eseguendo due richieste di pull, eseguendo due revisioni di codice, facendo due ... all'infinito.
Per evitare di accoppiarli potrebbe essere anche peggio: sarà necessario che il client sia in grado di supportare più versioni del server e che il server supporti diverse versioni del client, nascondendo voci di menu che richiedono funzionalità rilevate come mancanti sul server, supportando o altrimenti gestendo messaggi e parametri obsoleti dai vecchi client. Sarà necessario essere in grado di QA nuove funzionalità su entrambi i lati in modo indipendente da apportare le stesse modifiche all'altro repository, questo include sia il test automatico (ciò che avrebbe potuto essere una suite di test di integrazione sono ora tre: test di integrazione del client, test di integrazione del server e test end-to-end) e test di accettazione degli utenti (i vostri stakeholder possono utilizzare API REST e concludere se soddisfano le loro esigenze?) In caso contrario, preparatevi a costruire le cose più volte. il server che lo supporta? Divertiti a scrivere molti stub.). A seconda della tua applicazione, ciò potrebbe essere semplice, molto lavoro o effettivamente impossibile, quindi dovresti essere abbastanza sicuro che i vantaggi organizzativi di avere repository separati siano superiori ai costi.
Se si desidera che il server sia il server e il cliente come client, per essere in grado di conformarsi alle convenzioni del framework di scelta di ogni componente senza compromessi, per avere un confine pulito tra i prodotti nel progetto ( una linea di demarcazione costituita interamente dall'API) ottieni tutto questo con un paio di sottodirectory e un paio di comandi "cd" nel tuo script CI, e non rinunciare alla possibilità di cambiare cose come il nome di una risorsa o un parametro su entrambe le parti con un commit, una revisione, una distribuzione, ecc.