CouchDB is really fun. The rules are very tight, but consistent, and it quickly appears to be a shotgun to cause a lot of damage with. Especially with good with Javascript on the client side. There is a native Javascript driver and the protocol is RESTful (HTTP GET, PUT, DELETE).
Compare the the closest NoSQL alternative, MongoDB. I say close because they are both document stores (fancy key/value) with indexing and map/reduce.
MongoDB is very lean and blazing fast. But there isn't anything close to an HTTP layer in Mongo. It speaks in a binary JSON protocol. The format, commands, and driver, while well done, are a whole new set of rules to learn. Plus a Ruby middleware to talk HTTP.
My conclusions are from writing a simple app with both backends. Punchline: After all this experimentation I realize I need a relational DB for my project.
This is really cool, especially with companies now providing CouchDB hosting.
The article says that writes can be validated so only authorised users may write. Does anybody know if its possible to limit read access to certain users? If so, I may revive an abandoned project and try it as a CouchApp.
Read access is on a per-database basis. So if you have a work group only Joe, Anne, and Robert should access, you can give them a database, with their own copy of the app running in it. We don't do per-document read-control because it becomes to complex to manage in real world situations.
Great to see that feature... I only played with CouchDB in 0.7-days before shows and lists, and found it too everything-is-public for my needs.
Let's suppose I want to build a centralized messaging application where users send each other private messages (and let's say per-user couches aren't available). Users may only see messages directed to them. Messages are contained in documents, one document per message (sounds like a reasonable granularity).
For the JavaScript front-end, I'd like to ask the server for a list of messages for the current user, and later on, for the contents of one particular message.
The list of messages for one user sounds like a simple map-reduce view. In order to only show messages targeted to the current user, my guess is that I should add a list function to the same design document to remove other users' items from the view result. To fetch a message by ID, I'd install a show function which either returns the original message as JSON text or an invalid access message, depending on the current user. Is that how you'd use shows and lists?
Yes that would work. You could go a bit further, though:
Set your view to emit keys this way:
[user,message_id]
you can query the view using:
msgview?startkey=[user]&endkey=[user,{}]
which will give you all the messages for the given user, or
msgview?startkey=[user,message_id]&limit=1
for a specific message.
Then your list doesn't have to go through all the messages for all the users -- just the ones that the view returned -- and only check that their user info is correct (i.e. nobody's calling the list using an inapropriate view).
With this scheme you could have the same list + view return a specific message as well.
Oh, and definitely go check CouchDB 1.0 -- it's changed quite a bit since 0.7. You can get a hosted version to play with at http://www.couch.io/get.
If you want to allow the users to take the db offline, you will still be happiest giving each user or group their own database. Databases are just a file on the server, and CouchDB has been deployed with millions of databases on a single server. So the one database per user model is totally viable.
In fact, the bad old days are still with us, as most applications still rely on fragile custom code, running in an application server like Ruby on Rails, Python's Django, or some kinda Java thing.
I'm pretty sure the fragility of the code is as much down to the person writing it as it is to the platform. I don't think it's fair to say that application servers are inherently fragile; run Python or Java apps on App Engine and you're unlikely to ever have a genuine scaling problem...
Last I checked it is still possible to send an email from inside a Rails controller, or to update a bunch of database records in a tight loop. You can't do these sorts of things at scale, which a lot of people are still learning the hard way.
Part of an app server like Django et al being flexible is giving you the ability to shoot yourself in the foot. It is much harder to screw something up royally when you are working within the CouchApp constraints. That's what I meant by fragile.
Google App Engine gets this mostly right by enforcing draconian timeout limits and other constraints, so it is much harder to write an app that is gonna fall over under a big wave of traffic, as the sandbox will complain right away.
CouchApp is even more picky. The programming model doesn't have operations that could block on remote IO, so you can't even go down the bad path. Of course, when you do need to send an email, you've got to rethink how to do it. (Actually in a real app you'd do email from an asynchronous task as well.)
There isn't a strong consensus. I've seen e-mail > quoting (as I used), italics, "quotes", etc. It usually isn't a big deal, unless using several kinds of quoting makes your intent unclear.
If an app can be replicated to a user's machine, can the user then also manipulate the couchapp's view and design documents using futon or otherwise, even though validation functions are in place?
ie, would a user be able to alter the application themselves, and not just their data?
Yes, depending on how the access and security is setup. If the user has access to the database, they can just open the _design document and edit the html template, JavaScript code, the view, list and show functions.
For those that are still confused a bit, couchapp takes advantage of the fact that couchdb is accessed via a RESTful interface. Documents and databases are identified and accessed with URLs.
Typically your client and couchdb speak JSON to each other. When you GET a resource, you just get back a JSON object.
However:
1. You can change the format of what you get back. You can also return back XML, HTML, XHTML, etc., instead of JSON.
2. You can add attachments to documents. Attachments can be images, html pages, anything. You can specify the content type and couchdb will happily serve those when you click the attachment resource URL.
CouchApp takes advantage of those 2 things. It renders html page templates saved as document attachments, and fills those in with data from some view (read: query), and then returns HTML.
It basically cuts out the traditional middle layer by performing that work inside the database.
Combined with the fact that replication works so well in couchdb, you can just move your web app just by replicating a database: a one-step process.
Couch's design documents are protected, even though they are replicated, as you say. Unless I'm misunderstanding your question, your application will be safe from modification, as it will be update-able only by the author.
Actually, whatever is on the user's machine (or in a Couch in the cloud controlled by the user) is 100% under the control of the user. They are free to alter the application, validations, etc, as they see fit.
However, when the user attempts to replicate changes to another server (maybe the original source server, maybe another server not under their control) it is the validation functions on the target server that control which writes are allowed to proceed.
So if my http://jchrisa.net server only allows updates from me (for instance for blog posts), you can still replicate my blog to your machine, and edit posts there, but when you replicate the changes back to my server, they will be rejected by my validation function.
Thank you; that is what I meant to explain, but you were much more clear. I guessed that wil was asking about the safety of his own application once replicated by others, because I don't see the concern of having users replicate their own copy, as long as the damage is contained.
Right, I was asking about the safety of the application that I write.
So any app written on couchapp can be considered to be modified by the end user if it's replicated to their machine. Then any application where you don't want users fiddling around with your 'source' is out of the question.
That said, there's plenty of applications that you'd want to pass along with the user's own data that you'd want the end users to fiddle with and improve.
With that in mind then, I'm guessing you can have validation functions that allow you to selectively update the design documents that you want from another person's changes, just as I can selectively replicate data from another person's copy of the couchapp.
Validation funs give you a lot of control over the update logic. However, they cannot be used to grant anonymous write access to application code. The design document may only be updated by the database or server admin.
That's a lot like my last web app before I started using CouchDB. Before I made the switch I was storing JSON in text fields in Postgres. Views are much better than the hoops I had to jump through to query that.
What about user input validation? If I understand it correctly, all the application code resides in the browser. This means that there is no server side code to make sure that the data stored in the database is properly sanitized. For example, how would you go about making sure an input doesn't contain HTML code? If the verification is made on the client side, it is easy to circumvent it.
Compare the the closest NoSQL alternative, MongoDB. I say close because they are both document stores (fancy key/value) with indexing and map/reduce.
MongoDB is very lean and blazing fast. But there isn't anything close to an HTTP layer in Mongo. It speaks in a binary JSON protocol. The format, commands, and driver, while well done, are a whole new set of rules to learn. Plus a Ruby middleware to talk HTTP.
My conclusions are from writing a simple app with both backends. Punchline: After all this experimentation I realize I need a relational DB for my project.