È possibile, ma in generale non è saggio offrire un accesso SQL diretto a un database.
- Devo rendere il database pubblicamente raggiungibile. Questo da solo mi renderebbe nervoso, poiché aumenta la superficie di attacco e la possibilità di perdita di dati.
Le configurazioni normali terrebbero il DB su una intranet e un server web in un DMZ . Il server web può quindi essere autorizzato per la connessione al DB.
-
Devo impedire accessi non autorizzati o modifiche ai dati e garantire un modello di dati coerente. Nessun utente dovrebbe essere in grado di danneggiare il mio database. Poiché diversi utenti hanno accesso a diversi record, avrei bisogno di creare un account utente di database per utente finale. Potrei dover sviluppare un sistema di viste del database e stored procedure per fare in modo che il modello di dati si adatti a questo modello di autorizzazione.
Una normale web app controlla il permesso nel codice dell'applicazione Web sul server e, pertanto, non deve limitarsi al modello di autorizzazione del database. Ciò consente modelli di autorizzazione su una granularità più adatta, ad es. concetti di dominio problematici anziché tabelle di database. Un tale schema può essere molto più semplice e quindi più sicuro.
-
Non riesco a limitare le query SQL specifiche che verranno inviate. Le query possono essere scritte in modo subottimale, quindi prestazioni di hogging. A meno che il database non fornisca supporto esplicito, non posso aggiungere cache o limitazione della velocità.
Al contrario, puoi ottimizzare le query che usi in un server web e utilizzare numerose tecnologie di memorizzazione nella cache.
-
Quando gli utenti si collegano direttamente al DB, il database è diventato la piattaforma dell'applicazione. Ciò rappresenta un sostanziale blocco in una particolare tecnologia e in un particolare modello di dati. Scalare un server di database è anche più difficile rispetto al ridimensionamento dei server delle applicazioni.
Al contrario, la maggior parte delle applicazioni Web acquisisce una certa scalabilità per impostazione predefinita solo dall'esecuzione del database e di qualsiasi logica applicativa su server diversi.
Se tieni tutto questo in mente, è possibile creare applicazioni incentrate sul database. Questo può essere un buon approccio, ad es. per applicazioni intranet in cui puoi fidarti di tutti gli utenti. Ma a causa dei problemi piuttosto sostanziali, questo non è generalmente consigliabile.
GraphQL è strano perché trasforma il tuo webserver in mezzo server di database. Tuttavia, hai la possibilità di implementare modelli di sicurezza personalizzati, implementare il caching e offrire un'API più conveniente rispetto a SQL non elaborato.
Le API REST "reali" (ad esempio, non GraphQL) sono concettualmente molto semplici e pertanto rendono molto semplice l'implementazione di controlli di sicurezza (probabilmente uno o due if-condizioni per endpoint) e sono molto facili da memorizzare nella cache. Il loro svantaggio (che gli indirizzi GraphQL) è che ottieni spesso più dati del necessario e ottieni solo una singola risorsa per richiesta.