L'applicazione di amministrazione dovrebbe utilizzare l'API o dovrebbe accedere direttamente al DB?

Poiché stai già scrivendo un'API per i tuoi clienti delle app, hai già una libreria di modelli di business e logica. Avere il sistema di amministrazione accedere ai dati tramite l'API significa che non devi replicare quella logica, il che significa meno possibilità di una discrepanza tra le interazioni delle app client con i tuoi dati e il tuo sistema di amministrazione.

Tuttavia, c'è da considerare la sicurezza. Per sua natura, un sistema di amministrazione avrà poteri piuttosto ampi di elencare i dati, possibilmente includendo i dettagli dell'account utente, e di modificare tali dati - ben oltre ciò che le app client dovrebbero essere in grado di fare.

Per evitare la replica in caso di logica: crea l'API del client e poi estendi la tua API di amministrazione. In questo modo, se la logica del core cambia, dovresti cambiarla solo una volta.

Creare un'API e creare un pannello di amministrazione sono due cose completamente separate. L'API deve essere il più leggero e veloce possibile, il pannello di amministrazione dovrebbe essere di facile utilizzo.

Poiché le responsabilità del progetto sono completamente diverse, anche i membri del team che lavorano su di loro.

Oltre a molte altre cose ...

Per il pannello di amministrazione avrai bisogno di persone che:

• capisci UX,
• progettazione di interfacce grafiche,
• codice UI grafico,

per API , d'altro canto, hai bisogno di persone che:

• capire gli standard API,
• sapere come profilare le applicazioni,
• sapere come costruire sistemi scalabili e performanti.

Se osservi il sommario di base delle persone che stai cercando per ogni progetto, puoi vedere che ha molto poco senso inserire il codice del pannello di amministrazione direttamente nel progetto API. Come sviluppatore di back-end non mi importa meno del tuo front-end.

Se cambi un colore di un pulsante così sia, ma Dio non voglia che questo cambiamento rovini il mio repository git dove sto trattando i problemi di risposta che vengono restituiti in 800 ms anziché in 150 ms (e viceversa, dubito di un lo sviluppatore front-end è interessato a cache, code, ...).

Le tue preoccupazioni per le prestazioni non sono nulla di cui preoccuparsi. Il pannello di amministrazione è accessibile solo agli amministratori di detto sistema. È raro che una pagina di amministrazione sia caricata incredibilmente veloce e "più lenta" (la differenza in realtà è di pochi ms) i tempi di caricamento non sono un problema.

Disaccoppiamento a parte, l'altro vantaggio di separare i progetti è una maggiore sicurezza. Non hai credenziali sensibili in due progetti (o nei loro script di compilazione appropriati) ma solo uno: il progetto API. Se decidi di assumere un nuovo programmatore per il front-end, in alcuni casi puoi ottenerlo e farlo funzionare anche senza firmare una NDA perché non c'è nulla che possa essere compromesso nel pannello di amministrazione - non hanno accesso diretto al database .

Assumere lo sviluppatore dell'API potrebbe essere un processo più lungo in cui una NDA firmata è un requisito per fornire loro l'accesso al codice.

Prendendo in considerazione il primo dei principi SOLID (principio di singola responsabilità) a livello di moduli, separerei l'app API dall'app di amministrazione. Questo è sempre il caso della manutenibilità e della flessibilità del software. Ti dà anche la possibilità di trovare gli eventuali bug più facili.

Separa l'applicazione di amministrazione dall'API. Il rendimento probabilmente andrà bene, non limitare le opzioni in base a "intuizioni" .

La tua descrizione non punta a colli di bottiglia evidenti. Sebbene sia una buona idea tenere d'occhio le prestazioni, è anche una ragione molto comune per l'ottimizzazione prematura.

Riconsiderare solo se si misurano problemi di prestazioni reali .