couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Bartell <>
Subject Re: Curiosity how you use CouchDB in your web env.
Date Fri, 08 Mar 2013 09:31:58 GMT
This is interesting discussion.  
Couch is pretty powerful on its own.  Powered by mochweb, its damn fast.  The proxying and
externals features are real sweet and lets one couch proxy to other couch's plus any web services.
 Given that, my stack is a bit different.

For the product I work on, I put Couch behind nginx. Nginx serves all the web apps. I don't
use any couch apps at all.  It a world I've wanted to explore, but really have no reason since
nginx is doing its job.  I've never seen performance issues from nginx.  The bottleneck usually
is couch.
Any special web services are usually node servers kept alive by forever.  Nginx also proxies
to them.  I originally had couch proxy to these services, but in the end had nginx serve them
As for users, they have direct access to couch and have their own databases.  I want to lean
on Couch's security as much as possible.  We originally considered having users share databases,
and then use filtering to serve their docs, but that seemed like a nightmare.  Heres my problems
with that.
1) The data no longer belongs to the users.  Each doc would need information about user rights

2) When user access rights change, a full reindex of views would need to take place. Imagine
databases with millions of docs and rights changing somewhat frequently.
3) All indices would grow faster due to the fact that they would need to include a user level.

Id love to hear if/how people are using the filtered shared database approach for multiple

If I had it to do over again, its hard to say if I would have abandoned nginx and just used
couch's proxy, externals, and couchapps  I really like separating all the things. i.e., Couch
as a datastore, nginx as a reverse proxy, web services controlled outside of couch.  I'm either
not seeing the light or ignorant.

Who knows, maybe in a few years when I really learn to wield all things couch, I would be
more comfortable in using couch all the way down.

On Mar 7, 2013, at 7:06 PM, Lance Carlson <> wrote:

> Keep me posted on your decision. I just node in front and also hit the same
> node process with background processing. Very curious about what others are
> choosing any why.
> On Thu, Mar 7, 2013 at 9:54 PM, Jeff Charette <> wrote:
>> For my use case I would like to take advantage of couches replication and
>> putting something in front of couch seems it complicate that.  Also, I
>> don't want couch to touch any credit information and simply like to pass
>> through to a service.  Externals seems a good use case for this, but node
>> in front would get the job done as well.  The more I think about it though
>> I may put node in front because I have not been able to pass a POST request
>> through externals.
>> Jeff Charette | Principal
>> We Are Charette
>> web / identity / packaging
>> m  415.298.2707
>> w
>> e
>> On Mar 7, 2013, at 4:37 PM, Lance Carlson <> wrote:
>>> Jeff,
>>> I just started probing at the externals API. Didn't know what it did
>>> exactly and it looks cool. What are the advantages/disadvantages of using
>>> that vs using something node as a proxy to couch?
>>> On Thu, Mar 7, 2013 at 12:54 PM, Tim Anderson <>
>> wrote:
>>>> Anybody using couchdb as data layer with Grails?
>>>> On Thu, Mar 7, 2013 at 11:38 AM, Jeff Charette <>
>> wrote:
>>>>> I use pure couchapps backed by node processes for transactions.
>>>>> I use kanso to manage my couchapps.  May switch to just grunt and
>> manage
>>>>> packages on npm.
>>>>> For security everything goes through rewrites then design doc shows,
>>>>> lists, updates.  This messes up my ability to upload attachments since
>> I
>>>>> need secure_rewrites.  I am currently working through the database per
>>>> user
>>>>> setup as well.
>>>>> Also would love to hear how people are using externals.  I am passing
>>>>> transactions request directly to externals then to node, but have only
>>>> been
>>>>> able to do GET request.  Finally, I set the state of a document on
>> couch
>>>>> when the node process is complete.  I do have a question of how people
>>>> are
>>>>> authenticating back to couchdb.  Is the AuthSession cookie enough?
>>>>> Jeff Charette | Principal
>>>>> We Are Charette
>>>>> web / identity / packaging
>>>>> m  415.298.2707
>>>>> w
>>>>> e
>>>>> On Mar 7, 2013, at 10:57 AM, svilen <> wrote:
>>>>>> probably, for going this way, one might use non-blocking
>>>>>> long_poll webframework like python/Tornado to wrap couchdb
>>>>>> replication/changes feed too. Thus something like
>>>>>> http:(someuserauth)//appserver/mychannel can route to couchdb's
>>>>>> changes for that database - or even aggregation - for that user even
>>>>>> if notion of user is not at all couchdb's one.
>>>>>> haven't tried it though.
>>>>>> On Fri, 8 Mar 2013 00:47:38 +0900
>>>>>> TAE JIN KIM <> wrote:
>>>>>>> Daniel,
>>>>>>> So basically, what you r saying is that you put application layer
>>>>>>> front of couch, so user no direct access to the couch.. Right?..I
>>>>>>> think you did pretty much similar thing #2 in my original post...
>>>>>>> BTW, just out of curiosity,  by doing this, any performance
>>>>>>> degradation / or any trouble stuff you may have to face with
>>>>>>> something you might had not expected at all ?...
>>>>>>> Thanks,
>>>>>>>> From:
>>>>>>>> Date: Thu, 7 Mar 2013 16:37:36 +0100
>>>>>>>> Subject: Re: Curiosity how you use CouchDB in your web env.
>>>>>>>> To:
>>>>>>>> Well, if things were always so easy!
>>>>>>>> We have this scenario: our webapp has to server data to different
>>>>>>>> organizations (hopefully thousands, if our product sells
>>>>>>>> That means we can not partition data in different databases:
>>>>>>>> would be a maintenance nightmare. can somebody tell me how
>>>>>>>> - upgrade the design docs in 1000 databases without going
>>>>>>>> - How to backup them?
>>>>>>>> - ...
>>>>>>>> I mean, the more databases you have, the more complicated
>>>>>>>> maintenance becomes. Maybe that can be automated, but it
is not
>>>>>>>> easy out of the box.
>>>>>>>> Besides, I do not want to implement the following:
>>>>>>>> - new organization signs-up
>>>>>>>> - we create a new database for it
>>>>>>>> - we upload the design documens
>>>>>>>> - we trigger those documents
>>>>>>>> I mean, it is probably doable, but I am not walking that
path right
>>>>>>>> now. So, the only way that I know of in which we can partition
>>>>>>>> data is by having an application server in front of couch:
a single
>>>>>>>> database for all customers, with access control implemented
>>>>>>>> view filtering with the org_id as key. The user has no direct
>>>>>>>> access to couch.
>>>>>>>> On Wed, Mar 6, 2013 at 7:42 PM, Robert Newson <>
>>>>>>>> wrote:
>>>>>>>>> Don't grant users access to databases you don't want
them to
>>>>>>>>> read. :)
>>>>>>>>> B.
>>>>>>>>> On 6 March 2013 12:33, Mark Hahn <>
>>>>>>>>>> Anyone logged in can read any document in the DB.
 I have to
>>>>>>>>>> check each user and what they are trying to do to
block illegal
>>>>>>>>>> actions.
>>>>>>>>>> On Wed, Mar 6, 2013 at 9:51 AM, Robert Newson
>>>>>>>>>> <>
>>>>>>>>> wrote:
>>>>>>>>>>> "How does everyone solve the security issue?"
>>>>>>>>>>> What security problem? Only administrators can
modify design
>>>>>>>>>>> documents.
>>>>>>>>>>> B.
>>>>>>>>>>> On 6 March 2013 11:38, Aurélien Bénel <>
>>>>>>>>>>> wrote:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>> just out of curiosity, would like to
hear how CouchDB is
>>>>>>>>>>>>> being used
>>>>>>>>> in
>>>>>>>>>>> your web environment....
>>>>>>>>>>>> We have two main setups:
>>>>>>>>>>>> - CouchApps,
>>>>>>>>>>>> - REST APIs used by heavy clients (Java or
>>>>>>>>>>>> extensions) and
>>>>>>>>>>> attached Web applications.
>>>>>>>>>>>>> How does everyone solve the security
>>>>>>>>>>>> We always use CouchDB behind a reverse proxy
to add LDAP
>>>>>>>>> authentication
>>>>>>>>>>> and authorization when needed.
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> Aurélien

View raw message