couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <>
Subject Re: CouchDB Architecture for Modern Web Applications
Date Tue, 10 May 2011 02:48:46 GMT
I think these are good questions.

It is important, if you are gonna build a replicating app, that you
get used to thinking of replication filters as the security model.

Validation functions and replication filters.

Per document ACLs get hard to maintain (each query engine had to
respect them, and if the user really cares, they could just grep the
.couch file.)

So to really be secure, you have to think in terms of replication.

Now that we have the _replicator DB coming in 1.1, it will make it
easy to make CouchApps that manage replication. This way we can make a
super simple tool to keep Couch Apps running.

I fully agree we need more replicator tooling.


On Mon, May 9, 2011 at 2:23 PM, Marc Grabanski <> wrote:
> 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 (
> 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

Chris Anderson

View raw message