È una buona idea sviluppare un sito Web che abbia solo un accesso limitato al DB? CRUD sarà fatto chiamando l'API fornita dal sistema di backend interno separato

Come si dice in Informatica, "Un livello di riferimento indiretto risolve ogni problema" .

Puoi visualizzare ciò che sviluppi come Architettura orientata ai servizi . L'applicazione front-end consuma i dati recuperati dall'applicazione back-end. Insieme, formano un servizio. (L'applicazione front-end potrebbe essere eseguita sul computer dell'utente, se è un thin client, ad esempio realizzato in JavaScript, o potrebbe essere eseguito sui computer, se è un client grasso che deve eseguire calcoli complessi o deve accedere ad altre risorse che non sono sul computer dell'utente).

Il principale vantaggio di questo specifico "costruire un livello di riferimento indiretto" è che stai estraendo il tuo modello di dati di base. Molti clienti diversi possono recuperarlo utilizzando la stessa API: un client di app mobile, un sito di amministrazione non accessibile da Internet o un client incorporato in un satellite che circonda la Luna. Inoltre, sei libero di scambiare il modo in cui sono archiviati quei dati principali: a te, vengono recuperati da un DB, ma a questi clienti non interessa se la prossima settimana il backend recupera i dati da un file flat o da un archivio di valori-chiave NoSQL .

Lo svantaggio principale è che questo potrebbe essere eccessivo se si sta costruendo un sito Web semplice che viene utilizzato all'interno di una intranet.

Come osserva @RobertHarvey, la tua preoccupazione per le prestazioni è infondata. In effetti, la possibilità di scambiare backend potrebbe consentire di scalare su hardware o software molto più performante senza che i client se ne accorgano.

Altri pro e contro: ricorda di avere un protocollo molto chiaro tra frontend e backend - cosa era prima che un'interfaccia tra i pacchetti ora sia diventata un'API remota. È utile avere una chiamata API che restituisce la versione o le funzionalità API. Se il cliente chiama Internet, ricorda che potrebbero essere falsificati: prova a crittografarli e firmarli, come se fossero messaggi che arrivano al tuo ufficio centrale dalle filiali locali.

In pratica stai descrivendo un livello di servizio .

I tuoi problemi relativi alle prestazioni sembrano infondati. In pratica, il tuo livello di servizio tradurrà semplicemente la tua API nelle necessarie API di terze parti o chiamate SQL; l'overhead dovrebbe essere minimo.