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: local policy)
Message-ID: <52CEB873.7080404@ironicdesign.com>
Date: Thu, 09 Jan 2014 08:55:47 -0600
From: Andy Dorman <adorman@ironicdesign.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:17.0) Gecko/20131005 Icedove/17.0.9
MIME-Version: 1.0
To: user@couchdb.apache.org
CC: Ironic Design Development <devel@lists.ironicdesign.com>
Subject: Re: A CouchDB/Cloudant Scale & Authorization question
References: <52CEAA59.2060108@ironicdesign.com>
 <FD424C2E-5CD6-4922-878C-D9B7E4BD5645@cloudant.com>
In-Reply-To: <FD424C2E-5CD6-4922-878C-D9B7E4BD5645@cloudant.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 01/09/2014 08:33 AM, Adam Kocoloski wrote:
> Hi Andy, you're right that a DB per user-feature is currently the way to go to achieve the kind of access control granularity that you have in mind.  100k databases in a Cloudant account is not all that uncommon.  Cheers,
>
> Adam
>
> On Jan 9, 2014, at 8:55 AM, Andy Dorman <adorman@ironicdesign.com> wrote:
>
>> Hi, we are new to document databases and CouchDB, but we are very excited about the possibilities of CouchDB, Cloudant, and PouchDB, especially for mobile applications.
>>
>> We are beginning a major update to a "mobile first" design of a web app that has used an SQL db for over 13 years.  The app currently has thousands of users (and will hopefully grow to tens of thousands once we have a mobile version running) with 10 "shareable" features (Calendar, Recipes, etc.) for each user.  Each user needs to be able to grant "read" or "edit" access to each feature to some number (usually anywhere from 2 to 50) of other users.
>>
>> This access model needs read/write authorization to be per user per feature. ie, Joe (a user) can grant edit access for his Recipes (a feature) to his Mom (another user) and read access for his Calendar (another feature) to his wife (another user).
>>
>> We really want to use Pouchdb in the client and Couchdb/Cloudant on the server-side as that solves a LOT of issues regarding replication and network access for mobile clients.
>>
>> However, it looks to us like the only way to implement this access model using CouchDB's built-in auth features is to define a database for each user-feature combination.  So Joe could grant edit access to his "Recipe database" to his Mom and read access to his Calendar database to Fred and edit access to his wife.
>>
>> Our first question is: Is it scalable for an app with several thousand(s) users and 10 features to use a separate database for each user-feature? With 10,000 users and 10 features, that would come to 100,000 "databases" for our app.
>>
>> The second question would be is there another way (other than us writing a server-side middle layer REST-ful app to handle authorization) to handle authorization at a per user per feature level?  Our original design using CouchDB had a single database per user and a doc-type or document per feature.  But we have been unable to figure out a way to have CouchDB control authorization for each document or doc_type.
>>
>> Thank you for any insight or references to documentation that might explain a way to implement CouchDB authorization at the doc_type or document level.
>>
>> --
>> Andy Dorman
>>
>

Excellent!  Thank you Adam.

Having that many "databases" for a single app just did not seem 
"natural".  :-)  However, we realize that we have several misconceptions 
based on many years of SQL experience that we are going to have to 
"unlearn".

We are really looking forward to working with Cloudant and PouchDB.

Sincere regards,

-- 
Andy Dorman