couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lance Carlson <>
Subject Re: Curiosity how you use CouchDB in your web env.
Date Fri, 08 Mar 2013 15:27:54 GMT
To clarify, by client I meant node js, not the browser.

Sent from my iPhone

On Mar 8, 2013, at 4:32 AM, Stephen Bartell <> wrote:

> 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 instead.
> 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
> 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
> 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
>>> I
>>>>>> need secure_rewrites.  I am currently working through the database
>>>>> 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
>>>>> 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
>>>>>>> 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 in
>>>>>>>> front of couch, so user no direct access to the couch.. Right?..I
>>>>>>>> think you did pretty much similar thing #2 in my original
>>>>>>>> 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
>>>>>>>>> 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 to:
>>>>>>>>> - 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 the
>>>>>>>>> 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
>>>>>>>>> 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 Firefox
>>>>>>>>>>>>> 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