Return-Path: X-Original-To: apmail-couchdb-user-archive@www.apache.org Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 7AD6CE65D for ; Fri, 8 Mar 2013 15:26:07 +0000 (UTC) Received: (qmail 69006 invoked by uid 500); 8 Mar 2013 15:26:05 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 68798 invoked by uid 500); 8 Mar 2013 15:26:04 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 68771 invoked by uid 99); 8 Mar 2013 15:26:04 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 08 Mar 2013 15:26:04 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of lancecarlson@gmail.com designates 209.85.210.173 as permitted sender) Received: from [209.85.210.173] (HELO mail-ia0-f173.google.com) (209.85.210.173) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 08 Mar 2013 15:25:56 +0000 Received: by mail-ia0-f173.google.com with SMTP id h37so1583525iak.18 for ; Fri, 08 Mar 2013 07:25:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:from:in-reply-to:mime-version:date:message-id :subject:to:content-type:content-transfer-encoding; bh=LUACUfhZ6DIl2R4G7stsoHLR27yKnmo6omh7jUmySxU=; b=QL2GchguxeDFc5ID0KqPgJfdrgv53yShKtdefYWtd75gdxG5dl5kt6TTsgEAQSwy+Y H4GtOcMGU/LG8c+Fg8oVKBakodr6ev09062rxUU+mePCY6THwiSiJ4/ojI7s47P37re7 yhfm6+4oL3UxYNAejOSQa+haU4VLVKp5FUaCrii9VGzyRdeDS3AByabE6yIW/RApD5Uc U92VsLuTLSYvEzqpk2UHiewZfqmO8l5bLyOBrqIQSA8Zn2d3kI1558GooJMBLZtJasYo AwbSsgYEkKpYb/bDmCfSdtQguSFtmjJ/zl6pVfWE9ilyFngkQQWhcV4zYLvk03hYo1FW uAlA== X-Received: by 10.50.37.164 with SMTP id z4mr18155428igj.38.1362756335777; Fri, 08 Mar 2013 07:25:35 -0800 (PST) References: <20130307175739.6ef25c40@svilendobrev.com> <4223E3E8-E3C4-46C3-9B84-DBABFC00A836@yahoo.com> <05E8E87C-D69D-4F65-B2B9-8D04B8D71D72@yahoo.com> From: Lance Carlson In-Reply-To: Mime-Version: 1.0 (1.0) Date: Fri, 8 Mar 2013 10:25:36 -0500 Message-ID: <3425656131404671653@unknownmsgid> Subject: Re: Curiosity how you use CouchDB in your web env. To: "user@couchdb.apache.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org 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 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 prox= y to other couch's plus any web services. Given that, my stack is a bit di= fferent. > > 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 ex= plore, 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 service= s, but in the end had nginx serve them instead. > As for users, they have direct access to couch and have their own databas= es. 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 t= heir 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 informat= ion 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 som= ewhat 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 appr= oach for multiple users. > > If I had it to do over again, its hard to say if I would have abandoned n= ginx and just used couch's proxy, externals, and couchapps I really like s= eparating all the things. i.e., Couch as a datastore, nginx as a reverse pr= oxy, web services controlled outside of couch. I'm either not seeing the l= ight or ignorant. > > Who knows, maybe in a few years when I really learn to wield all things c= ouch, 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 s= ame >> 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 a= nd >>> 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 pas= s >>> through to a service. Externals seems a good use case for this, but no= de >>> in front would get the job done as well. The more I think about it tho= ugh >>> I may put node in front because I have not been able to pass a POST req= uest >>> 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 wrot= e: >>> >>>> 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 us= ing >>>> 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 sin= ce >>> I >>>>>> need secure_rewrites. I am currently working through the database p= er >>>>> user >>>>>> setup as well. >>>>>> >>>>>> Also would love to hear how people are using externals. I am passin= g >>>>>> transactions request directly to externals then to node, but have on= ly >>>>> 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 peop= le >>>>> 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 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 eve= n >>>>>>> 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 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 rig= ht >>>>>>>>> now. So, the only way that I know of in which we can partition th= e >>>>>>>>> data is by having an application server in front of couch: a sing= le >>>>>>>>> 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 >>>>>>>>> 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 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 >>>>>>>>>>> >>>>>>>>>> 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=E9lien B=E9nel >>>>>>>>>>>> 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=E9lien >