Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of m@marcgrabanski.com designates
 209.85.161.52 as permitted sender)
MIME-Version: 1.0
From: Marc Grabanski <m@marcgrabanski.com>
Date: Mon, 9 May 2011 16:23:52 -0500
Message-ID: <BANLkTime2WWi7DPeQkApQsgwJKeyygj1uw@mail.gmail.com>
Subject: CouchDB Architecture for Modern Web Applications
To: user@couchdb.apache.org
Content-Type: multipart/alternative; boundary=20cf3054a7b9b371ba04a2de768d

--20cf3054a7b9b371ba04a2de768d
Content-Type: text/plain; charset=ISO-8859-1

I am trying to resolve common threads that keep coming up when CouchDB is
discussed in the wild.

One major thing I see debated is the per-database ACL in CouchDB. Currently,
we have to assume that most applications will need to give each user their
own private database, unless they access couch through an application-tier
like rails -- this doesn't seem to leverage CouchDB's core strength of being
HTTP/REST-based out of the box.

So given each user has their own private database, the general use-case in
question is:
If a user has some info in their personal database they want to make public,
how do you make it easy to query across all of the public user data that is
left fragmented inside thousands of databases?

A possible solution seems to be replicating public information out to
another public database via some type of replication, but what if they
switch that data back to private, how would that public database be best
synced and kept up to date? I've heard filtered replication (
http://blog.couchbase.com/whats-new-in-apache-couchdb-0-11-part-three-new)
being thrown around, but maybe someone can take a stab at explaining
at a
high level how they would tackle this general use-case?

Typically in web applications you commonly need to:
- generate / search through a list of users
- aggregate and search all the public user information
- generate an activity feed based a person's friends or followers

How would these general use-cases be best architected in CouchDB? I am
seeing a lot of fallout from people who try to use CouchDB for those things
and eventually give up and go back to a relational DB because it is too
large of a departure for them to come up with a good solution.

Would you recommend these people go use a relational database for these
types of web applications, or are there general guidelines that would keep
these types of applications perfectly happy inside CouchDB? I think a
high-level explanation on this topic would be good since people seem to be
very confused when to use CouchDB, and more importantly when not to use
CouchDB for their web-based applications.

Sincerely,
--
Marc

--20cf3054a7b9b371ba04a2de768d--