Non esiste una soluzione "taglia unica" per questo, tutto si riduce alla domanda che cosa esattamente
in some way connected to the main one
significa. Se entrambe le applicazioni, specialmente dal punto di vista dei loro casi d'uso, sono strettamente accoppiate e intrecciate, con un'interfaccia tra loro che cambia frequentemente, allora potrebbe essere meglio non separarle. Se, tuttavia, possono essere separati in modo significativo, magari con una gestione di rilascio disaccoppiata, allora due applicazioni potrebbero essere la scelta migliore. Ma lasciatemi commentare alcuni dei tuoi pro e contro:
all application with the same UI
dipende da cosa intendi con questo: se intendi "UI dall'aspetto simile", questo è abbastanza indipendente dalla decisione per una o due applicazioni. Se intendi "solo un'interfaccia utente per entrambi", questa potrebbe essere un'indicazione che i casi d'uso sono così intricati che un'applicazione sarà migliore.
"single login" vs "implement a single sign on system between all the app"
è davvero un po 'più impegnativo quando si creano applicazioni separate, ma IMHO non dovrebbe essere il fattore trainante della decisione.
one big git project
non è necessariamente una brutta cosa, gestire troppi progetti git può effettivamente diventare uno svantaggio (ma ovviamente, quando crei app separate, sarai comunque libero di utilizzare un solo repository git). Repository git separati sono favorevoli se ci sono team diversi per ogni applicazione, e non ci sono librerie comuni riusabili nel repository, ma se c'è un solo team, posso immaginare che un repository potrebbe essere la decisione migliore - per entrambi gli approcci.
Quindi hai scritto
more difficulties to manage and release updates
sul lato di cono per "una sola applicazione" - che può essere effettivamente vero, o può essere falso, dipende. Se ci sono interfacce stabili tra le due applicazioni, puoi combinare in modo quasi arbitrario diverse versioni di app # 1 e app # 2, quindi pubblicare una versione più recente di app 1 o app # 2 sarà più facile. Se non ci sono interfacce stabili e ci saranno solo combinazioni di versioni specifiche di app # 1 e app # 2 compatibili tra loro, la gestione e il rilascio degli aggiornamenti per applicazioni separate aumenteranno i costi di gestione della configurazione e sarà probabilmente più facile per una singola applicazione.
duplicated libraries and common files
Quando hai due applicazioni con librerie comuni, quelle librerie non dovrebbero essere duplicate, dovrebbero essere riutilizzate da entrambe le applicazioni. Se si intende "duplicato sul server di produzione": lo spazio per le librerie tipiche è economico e le distribuzioni dovrebbero essere automatizzate da alcuni script, quindi la distribuzione della stessa lib due volte non dovrebbe creare problemi. E "file comuni": se ci sono cose in questi file che dovranno essere mantenute in entrambe le applicazioni in parallelo, prova a spostare gli elementi comuni in una libreria comune e riutilizzala.
TLDR; questo dipende in gran parte dalle esigenze del tuo caso individuale, funzionale e non funzionale.