Is CouchDB per-user database approach feasible for users with lots of shared data?

Question

I want to implement a webapp - a feed that integrates data from various sources and displays them to users. A user should only be able to see the feed items that he has permissions to read (e.g. because they belong to a project that he is a member of). However, a feed item might (and will) be visible by many users.

I'd really like to use CouchDB (mainly because of the cool _changes feed and map/reduce views). I was thinking about implementing the app as a pure couchapp, but I'm having trouble with the permissions model. AFAIK, there are no per-document permissions in CouchDB and this is commonly implemented using per-user databases and replication.

But when there is a lot of overlap between what various users see, that would introduce a LOT of overhead...stuff would be replicated all over the place and duplicated in many databases. I like the elegance of this approach, but the massive overhead just feels like a dealbreaker... (Let's say I have 50 users and they all see the same data...).

Any ideas how on that, please? Alternative solution?

Oleaceous

Answer 1

You can enforce read permissions as described in CouchDB Authorization on a Per-Database Basis.

For write permissions you can use validation functions as described on CouchDB The Definitive Guide - Security.

You can create a database for each project and enforce the permissions there, then all the data is shared efficiently between the users. If a user shares a feed himself and needs permissions on that as well you can make the user into a "project" so the same logic applies everywhere.

Using this design you can authorize a user or a group of users (roles) for each project.

Kathiekathleen

Unfortunately the per-project permission model is not fine-grained enough for my needs (I need some of the users to see only some of the items belonging to a certain project). – Oleaceous

Answer 2

Other than (as victorsavu3 has suggested already) handling your read auth in a proxy between your app and couch, there are only two other alternatives that I can think of.

First is to just not care, disk is cheap and having multiple copies of the data may seem like a lot of unnecessary duplication, but it massively simplifies your architecture and you get some automatic benefits like easy scaling up to handle load (by just moving some of your users' DBs off to other servers).

Second is to have the shared data split into a different DB. This will occasionally limit things you can do in views (eg. no "Linked Documents") but this is not a big deal in many situations.

Hellespont

Disk space is cheap - yeah, but in my case this would eventually result in lots of disk space being used so I decided not to go down this road. Splitting the DB - I thought about that too...but I believe that would make this approach more complex than running a thin server on top of CouchDB that handles the authentication. – Oleaceous