From the article: "CouchDB + Another Layer as Web Server is Redundant". This is very true, and the biggest difference to other databases I've used, NoSQL or not. It ends up being a double-edged sword for CouchDB.
On the one hand, it saves having to context switch between thinking about the database, thinking about the web server, thinking about the web framework, etc.. For a single developer, this is not to be sniffed at. As learning is often done by lone experimentation, it makes CouchDB an excellent system for learning about NoSQL. It's also great for prototyping, where you don't necessarily want to spend a huge amount of time creating an industrial strength back-end.
On the flip-side, it means that if you do run into a situation where you want to use another layer, you've just given up the biggest advantage of CouchDB. For my current project, I found I would need to be able to integrate authentication with an existing Kerberos system - the easiest way to do this was to use Apache.
I also had slight reservations about CouchDB's approach of limiting what you can do - everything has to be a map-reduce - to ensure scalability. The plan as I understand it is to introduce further safe operations down the road. I'm sure that approach will yield dividends, but for now it seems quite limiting - similar to eschewing C in the 70s because it does not have garbage collection.
Didn't mean to beat up on CouchDB too much - it's a fine system, but I prefer the flexibility of MongoDB at this point.
CouchDB is not as limiting as you suggest but it is a total paradigm shift. There is more to CouchDB than map-reduce.
In my view, CouchDB is more at home as a middleware layer than a database layer.
Take your current project as an example. Why not have Apache reverse proxy to CouchDB? You'd give up zero CouchDB functionality and would gain Kerberos authentication.
Putting another web server in front of CouchDB is unnecessary, but putting web proxy servers in front of it is totally useful. In other words, adding HTTP layers on top of CouchDB means you don't have to trade-off anything.
CouchDB lives and breathes HTTP. If you choose to keep your database from talking with the outside world directly, then CouchDB is a poor choice and you're right to go with MongoDB.
Don't let the name fool you, people. CouchDB isn't simply a place to stuff and retrieve JSON data.
You also give up replication, not only of the data, but of the entire web application. CouchDb's replication shouldn't be overlooked not as a technology, but in its various applications of a decentralized system.
On the one hand, it saves having to context switch between thinking about the database, thinking about the web server, thinking about the web framework, etc.. For a single developer, this is not to be sniffed at. As learning is often done by lone experimentation, it makes CouchDB an excellent system for learning about NoSQL. It's also great for prototyping, where you don't necessarily want to spend a huge amount of time creating an industrial strength back-end.
On the flip-side, it means that if you do run into a situation where you want to use another layer, you've just given up the biggest advantage of CouchDB. For my current project, I found I would need to be able to integrate authentication with an existing Kerberos system - the easiest way to do this was to use Apache.
I also had slight reservations about CouchDB's approach of limiting what you can do - everything has to be a map-reduce - to ensure scalability. The plan as I understand it is to introduce further safe operations down the road. I'm sure that approach will yield dividends, but for now it seems quite limiting - similar to eschewing C in the 70s because it does not have garbage collection.
Didn't mean to beat up on CouchDB too much - it's a fine system, but I prefer the flexibility of MongoDB at this point.