Quindi, diciamo che costruirò un clone di Stack Exchange e deciderò di usare qualcosa come CouchDB come mio backend store. Se utilizzo l'autenticazione integrata e l'autorizzazione a livello di database, c'è qualche ragione per non permettere al Javascript lato client di scrivere direttamente sul server CouchDB disponibile pubblicamente? Poiché si tratta fondamentalmente di un'applicazione CRUD e la logica aziendale è costituita da "Solo l'autore può modificare il proprio post", non vedo la necessità di disporre di un livello tra il lato client e il database. Utilizzerei semplicemente la convalida sul lato CouchDB per assicurarmi che qualcuno non inserisca i dati inutili e si assicuri che le autorizzazioni siano impostate correttamente in modo che gli utenti possano solo leggere i propri dati _user. Il rendering verrà eseguito sul lato client da qualcosa come AngularJS. In sostanza potresti avere solo un server CouchDB e un sacco di pagine "statiche" e sei a posto. Non avresti bisogno di alcun tipo di elaborazione lato server, solo qualcosa che potrebbe servire le pagine HTML.
Aprire il mio database fino al mondo sembra sbagliato, ma in questo scenario non riesco a pensare al motivo per cui finché le autorizzazioni sono impostate correttamente. Va contro il mio istinto come sviluppatore web, ma non riesco a pensare ad una buona ragione. Quindi, perché questa è una cattiva idea?
EDIT: Sembra che ci sia una discussione simile qui: Scrivere Web "server less" applicazioni
EDIT: discussione eccezionale finora e apprezzo il feedback di tutti! Sento che dovrei aggiungere alcune ipotesi generiche invece di chiamare CouchDB e AngularJS in modo specifico. Quindi supponiamo che:
- Il database può autenticare gli utenti direttamente dal suo negozio nascosto
- Tutte le comunicazioni del database avverrebbero su SSL
- La convalida dei dati può (ma forse non dovrebbe?) essere gestita dal database
- L'unica autorizzazione che ci interessa oltre alle funzioni di amministrazione è la possibilità solo a qualcuno di modificare il proprio post
- Siamo perfettamente a posto con chiunque sia in grado di leggere tutti i dati (TRANNE i record dell'utente che potrebbero contenere hash delle password)
- Le funzioni amministrative sarebbero limitate dall'autorizzazione del database
- Nessuno può aggiungersi a un ruolo di amministratore
- Il database è relativamente facile da ridimensionare
- C'è poca o nessuna vera logica aziendale; questa è un'app CRUD di base