
  Possible Duplicate:
  Writing Web “server less” applications  




So, let's say I'm going to build a Stack Exchange clone and I decide to use something like CouchDB as my backend store. If I use their built-in authentication and database-level authorization, is there any reason not to allow the client-side Javascript to write directly to the publicly available CouchDB server? Since this is basically a CRUD application and the business logic consists of "Only the author can edit their post" I don't see much of a need to have a layer between the client-side stuff and the database. I would simply use validation on the CouchDB side to make sure someone isn't putting in garbage data and make sure that permissions are set properly so that users can only read their own _user data. The rendering would be done client-side by something like AngularJS. In essence you could just have a CouchDB server and a bunch of "static" pages and you're good to go. You wouldn't need any kind of server-side processing, just something that could serve up the HTML pages.

Opening my database up to the world seems wrong, but in this scenario I can't think of why as long as permissions are set properly. It goes against my instinct as a web developer, but I can't think of a good reason. So, why is this a bad idea?

EDIT: Looks like there is a similar discussion here: Writing Web "server less" applications

EDIT: Awesome discussion so far, and I appreciate everyone's feedback! I feel like I should add a few generic assumptions instead of calling out CouchDB and AngularJS specifically. So let's assume that:


The database can authenticate users directly from its hidden store
All database communication would happen over SSL
Data validation can (but maybe shouldn't?) be handled by the database
The only authorization we care about other than admin functions is someone only being allowed to edit their own post
We're perfectly fine with everyone being able to read all data (EXCEPT user records which may contain password hashes)
Administrative functions would be restricted by database authorization
No one can add themselves to an administrator role
The database is relatively easy to scale
There is little to no true business logic; this is a basic CRUD app


Doing as you suggest creates a tight(er) coupling between your client side language and your database.

That can be okay - there's less code to write and maintain, and in theory debugging could / should go a little quicker.

On the other hand, it makes other aspects more difficult.  If / when you need to change either of those technologies, you'll have a harder time because of the tight coupling between them.

Protecting yourself against attacks will be (quite) a bit more difficult.  You're assuming that the client will always present nicely formatted requests to the database.  That presumes no one will ever hack the client side code to insert malicious statements.  In other words, they'll "borrow" your authentication mechanisms and replace the normal client code with theirs.  

I wouldn't recommend it, and many would vehemently tell you not to.  But it can be done.
