
First Impressions of Sitting a Web App on CouchDB - messel
http://www.victusspiritus.com/2010/09/04/first-impressions-of-sitting-a-web-app-on-couchdb/
======
edparcell
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.

~~~
shotgun
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.

------
messel
This guy Till is awesome, real world examples/strategy to scale with CouchDB

[http://till.klampaeckel.de/blog/archives/95-Operating-
CouchD...](http://till.klampaeckel.de/blog/archives/95-Operating-CouchDB.html)

[http://till.klampaeckel.de/blog/archives/84-A-toolchain-
for-...](http://till.klampaeckel.de/blog/archives/84-A-toolchain-for-CouchDB-
Lounge.html)

here's his github: <http://github.com/till>

------
knodi
I have used couchdb in large systems and small systems. CouchDB is at the end
of the day a DB use it as a DB don't embedded your webapp in it.

~~~
jchrisa
I'd say you can do either, depending on your requirements. Some of the biggest
CouchDB users use it as a scalable back-end. But some of the most exciting
uses are deploying personal web-apps to the desktop.

------
rb2k_
I always am annoyed when I read that CouchDB can "scale up and down". CouchDB
has NO internal concept of sharding. The only thing it can do is repliaction.
Riak and Cassandra can actually scale up and down, CouchDB can scale up and
down as much as MySQL can... (or did I miss something?)

~~~
couchdb
There is a recently open-sourced fork of CouchDB that does the sharding thing.
With this addition to the capabilities, CouchDB really can scale up to hundred
machine clusters.

<http://blog.cloudant.com/cloudant-core-is-open-source>

------
shotgun
You just made my day when you quoted my stackoverflow answer. Thanks, man.

~~~
messel
You're great answer helped me better understand the app/DB relationship, and
added value to the post. I should be thanking you, in fact I will. Thanks
shotgun!

------
messel
Scattered notes and links, trying to soak up as much of the design philosophy
as possible. I'll pick up with examples once I'm not such a scrub.

------
cageface
Is the idea supposed to be that a web client (html+js) reads and writes
directly to a CouchDB server? Where do you put business logic?

~~~
k33n
All business logic is in the database itself. It has ACL's and data validation
built into one feature (update validation) and as for deciding which data to
display and when, the map/reduce-based view API is extremely powerful.

Force yourself to use CouchDB for a project where you're handling large
amounts of data and you'll discover how incredible it really is. There's tons
of other great features you'l pick up along the way too.

------
seanmcq
Please note the distinction between high availability writes and lock-free
writes. CouchDB offers the former.

~~~
messel
As I understand you can always write to a node. Where's the lock?

