Return-Path: X-Original-To: apmail-couchdb-user-archive@www.apache.org Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id DFC645829 for ; Tue, 10 May 2011 02:49:14 +0000 (UTC) Received: (qmail 69104 invoked by uid 500); 10 May 2011 02:49:13 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 68975 invoked by uid 500); 10 May 2011 02:49:13 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 68967 invoked by uid 99); 10 May 2011 02:49:12 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 10 May 2011 02:49:12 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of jchris@gmail.com designates 74.125.82.54 as permitted sender) Received: from [74.125.82.54] (HELO mail-ww0-f54.google.com) (74.125.82.54) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 10 May 2011 02:49:08 +0000 Received: by wwd20 with SMTP id 20so5772352wwd.23 for ; Mon, 09 May 2011 19:48:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=5kNgCztenQdp4/J6UxquI1IYnik/8SUAO9QmwMi3Ev4=; b=JM1l3oKW/WXG+5rikcI4h+bu11zjNoBZrxu7hssEp/IIfVBYOf5pbMUuK/zaI0c/64 9IUXHhpnCRpZmZ4FgBYUi72lJcdlX0KXWR3XgShsc+sVRdibxcQwT88Xxced9xo+38YS XklrjYWMTagh/RxDqh7ltU5l1aODrFFVxzeRE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=hv0j42GLmKwgyfi5rzP3RhJZnpCu5Pr8/yocZjhu4kCPUdUGUsHMaRsLKAcaIVXi7F l8UQCpBp7hGTMkbKLkI9TqM1eltPLrhy5F0U19+LWgrEkWYhWybFuZwNxWSVP06Sn+NY g5joBJTeizlc7QxDyKCDBMlJ+e979QQN7Os1A= MIME-Version: 1.0 Received: by 10.227.183.133 with SMTP id cg5mr365597wbb.49.1304995726537; Mon, 09 May 2011 19:48:46 -0700 (PDT) Sender: jchris@gmail.com Received: by 10.227.139.204 with HTTP; Mon, 9 May 2011 19:48:46 -0700 (PDT) In-Reply-To: References: Date: Mon, 9 May 2011 19:48:46 -0700 X-Google-Sender-Auth: z0B1PWbOHlAJSZRfW_A6M_J0iXA Message-ID: Subject: Re: CouchDB Architecture for Modern Web Applications From: Chris Anderson To: user@couchdb.apache.org Content-Type: text/plain; charset=ISO-8859-1 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 ( > 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 > -- Chris Anderson http://jchrisa.net http://couchbase.com