PouchDB is optimized for the use case of one database per user, a logged in user has full access to a specific database that only they have access to (for shared data access you can use replication on the server side)
1. Any application layer is in effect a transform, with security and sanity constraints, on user input.
2. There is at least the degenerate case where user input does not need to be transformed, only constrained
3. And about those constraints. CouchDB requires you write a validation function, and it lives inside the database, again obviating the need for that logic in the application layer.
If you look at their demo code it has a username and password right in the javascript source - as you would expect - which means keen users could do all kinds of things.
Aye, which is why putting your administrative credentials in client-side JavaScript is an unspeakably bad idea.
Instead, serve {client,user}-specific keys from the server on request, or let the user generate them through a signin process in the frontend, say by using the _users database that CouchDB and Cloudant allow.
Yes. But it is demo code, meaning that the use case isn't production, it's education. And the UX of education is a lot worse when you have to begin by saying, "this will look different from yours" and "here's a whole extra layer of complication I'm going to introduce, but don't worry it's a best practice."
Exactly, the username / password combination is most certainly to make life simpler for a demo, would never expect someone to do that in real code.
I plan on extending the getting started tutorial with an extention that does a database oer user when logged in (via persona), it actually wont make the tutorial much more complex and gets very close to what it should look like in production (https://github.com/daleharvey/couch-persona)
"CouchApps" have worked like this for at least four years ... they've been replaced by erica[1] which is described at: https://github.com/benoitc/erica. It's broadly compatible with BigCouch.