couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Marca <>
Subject Re: CouchDB Architecture for Modern Web Applications
Date Thu, 12 May 2011 02:39:15 GMT
On Mon, May 09, 2011 at 07:48:46PM -0700, 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.

I for one would really appreciate more documentation and examples on
building real world replication filters.

I'm saying that not having checked the Wiki or the couch book text
lately, so maybe it is there and I didn't understand what I was
reading the first time through.  If so I apologize and would
humbly accept pointers and scolding.

I remember reading a case study of a company that was using filtered
replication to expose some but not all data to their clients on a
client by client basis (something about bidding on jobs with spare lab
capacity where some jobs were confidential).  That was really cool,
and I would love to know how to do something like that, but I can't
figure it out on my own.

> 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

James E. Marca
Institute of Transportation Studies
University of California
Irvine, CA 92697-3600

View raw message