incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lance Carlson <lancecarl...@gmail.com>
Subject Re: Curiosity how you use CouchDB in your web env.
Date Fri, 08 Mar 2013 15:25:36 GMT
I use nginx in front node in front of couch. Perhaps this is overkill
but I'm most comfortable with nginx serving to the public. Node
handles security and background jobs. Couch the rest.

I actually was curious if anyone had done any benchmarks of using
templates/handlebars with couch vs using node. I'm still debating
which part of my stack should handle the views. In general I like
having my database serve everything but I'm seeing that my apps is
perhaps not as snappy as I'm used to. Perhaps this is not couch's
fault (although I've done several apps now using couch with the same
average request time). Can anyone share their experiences?

Sent from my iPhone

On Mar 8, 2013, at 4:32 AM, Stephen Bartell <snbartell@gmail.com> 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
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
users.
>
> 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 <lancecarlson@gmail.com> 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 <iomatix@yahoo.com> 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  wearecharette.com
>>> e   jeffrey@wearecharette.com
>>>
>>> On Mar 7, 2013, at 4:37 PM, Lance Carlson <lancecarlson@gmail.com> 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 <timatbeat@gmail.com>
>>> wrote:
>>>>
>>>>> Anybody using couchdb as data layer with Grails?
>>>>>
>>>>>
>>>>> On Thu, Mar 7, 2013 at 11:38 AM, Jeff Charette <iomatix@yahoo.com>
>>> 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  wearecharette.com
>>>>>> e   jeffrey@wearecharette.com
>>>>>>
>>>>>> On Mar 7, 2013, at 10:57 AM, svilen <az@svilendobrev.com> 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 <snowebang@hotmail.com> 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
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: gonvaled@gonvaled.com
>>>>>>>>> Date: Thu, 7 Mar 2013 16:37:36 +0100
>>>>>>>>> Subject: Re: Curiosity how you use CouchDB in your web
env.
>>>>>>>>> To: user@couchdb.apache.org
>>>>>>>>>
>>>>>>>>> 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
well).
>>>>>>>>> That means we can not partition data in different databases:
it
>>>>>>>>> would be a maintenance nightmare. can somebody tell me
how to:
>>>>>>>>>
>>>>>>>>> - upgrade the design docs in 1000 databases without going
crazy?
>>>>>>>>> - 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
via
>>>>>>>>> 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 <rnewson@apache.org>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Don't grant users access to databases you don't want
them to
>>>>>>>>>> read. :)
>>> http://wiki.apache.org/couchdb/Security_Features_Overview#Authorization
>>>>>>>>>>
>>>>>>>>>> B.
>>>>>>>>>>
>>>>>>>>>> On 6 March 2013 12:33, Mark Hahn <mark@hahnca.com>
wrote:
>>>>>>>>>>> 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
>>>>>>>>>>> <rnewson@apache.org>
>>>>>>>>>> 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 <aurelien.benel@utt.fr>
>>>>>>>>>>>> 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
issue?
>>>>>>>>>>>>>
>>>>>>>>>>>>> We always use CouchDB behind a reverse
proxy to add LDAP
>>>>>>>>>> authentication
>>>>>>>>>>>> and authorization when needed.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Aurélien
>

Mime
View raw message