couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nitin Borwankar <>
Subject Re: CouchDB Architecture for Modern Web Applications
Date Tue, 10 May 2011 04:51:41 GMT
I have reservations about calling replication filters a "security model" since it is decided
by the recipient entirely. It is more of a spam filter. It doesn't prevent docs from *leaving*
my  host but relies on the recipient honor policy. I'd like to have an outgoing repl filter
before I am comfortable calling this security of any kind. Just sayin'. 

Sent from my mobile Internet device

On May 9, 2011, at 7:48 PM, Chris Anderson <> wrote:

> 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.
> Chris
> 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