Return-Path: X-Original-To: apmail-couchdb-marketing-archive@minotaur.apache.org Delivered-To: apmail-couchdb-marketing-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 42CDF181BF for ; Wed, 6 May 2015 06:48:16 +0000 (UTC) Received: (qmail 96595 invoked by uid 500); 6 May 2015 06:48:16 -0000 Delivered-To: apmail-couchdb-marketing-archive@couchdb.apache.org Received: (qmail 96559 invoked by uid 500); 6 May 2015 06:48:16 -0000 Mailing-List: contact marketing-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: marketing@couchdb.apache.org Delivered-To: mailing list marketing@couchdb.apache.org Received: (qmail 96547 invoked by uid 99); 6 May 2015 06:48:15 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 06 May 2015 06:48:15 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: message received from 54.76.25.247 which is an MX secondary for marketing@couchdb.apache.org) Received: from [54.76.25.247] (HELO mx1-eu-west.apache.org) (54.76.25.247) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 06 May 2015 06:47:50 +0000 Received: from smtpcmd01240.aruba.it (smtpcmd01240.aruba.it [62.149.158.240]) by mx1-eu-west.apache.org (ASF Mail Server at mx1-eu-west.apache.org) with ESMTP id DF22725331 for ; Wed, 6 May 2015 06:47:48 +0000 (UTC) Received: from mail-ie0-f169.google.com ([209.85.223.169]) by smtpcmd01.ad.aruba.it with bizsmtp id QWng1q01B3fuNmh01WnhTi; Wed, 06 May 2015 08:47:42 +0200 Received: by iecnq11 with SMTP id nq11so6897097iec.3 for ; Tue, 05 May 2015 23:47:41 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.50.209 with SMTP id e17mr6407405igo.37.1430894861136; Tue, 05 May 2015 23:47:41 -0700 (PDT) Received: by 10.107.57.193 with HTTP; Tue, 5 May 2015 23:47:41 -0700 (PDT) In-Reply-To: <0B891CED-B735-4D86-86D2-1C4CDF6BDE21@apache.org> References: <33BD4D82-787C-48D5-B963-FEEA4C0913CB@apache.org> <4209351E-F51E-4DB5-8A5F-8AB53DA21877@apache.org> <0B891CED-B735-4D86-86D2-1C4CDF6BDE21@apache.org> Date: Wed, 6 May 2015 08:47:41 +0200 Message-ID: Subject: Re: How do CouchApps fit into the CouchDB story? (Was: CouchDB Articles, Pills and Tutorials Ideas) From: Giovanni Lenzi To: marketing@couchdb.apache.org Content-Type: multipart/alternative; boundary=047d7bdca97ce8bb550515642bf7 X-Virus-Checked: Checked by ClamAV on apache.org --047d7bdca97ce8bb550515642bf7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable @ermouth > http://cloudwall.me/etc/json-editor.html =E2=80=93 gonna make it couchapp= editor, AWESOME... cloudwall already deals with documents and attachments, so you are already probably not too-far ahead.. That would be awesome!! That could really dramatically increase adoption-rate, by making CouchDB the first platform-independent and browser-only development environment for secure web applications. @jan > - a lose collection of features inside CouchDB that all have problems: > - rewrite: not flexible enough, web devs expect more options for routing Sorry... but Flexibility is probably the number one feature of Couchapps and rewrite handler. Also the complete independency between 3 layers: presentation, business logic and data provides huge development benefits.. it's not only academic definition https://www.smileupps.com/couchapp-tutorial-chatty#simplifieddevelopment https://www.smileupps.com/couchapp-tutorial-chatty-couchapp-design#chattyap= idesign https://www.smileupps.com/couchapps Moreover Couchapps have system administration benefits other approaches simply lacks: - enable system wide queries, essentials to real-word scenarios: like a simple "how many users have done that today?".. how can you do this type of query, and how practical it is with a "database-per-user" approach? - depending on your use case and the size of your data.. you can split data into single or multiple databases for historical purposes(a database per month/year) or depending on data type.. withouth the drawback of exponential and uncontrollable growth typical of "database-per-user" With this I'm not saying "database-per-user" is bad.. on the contrary, it's VERY GOOD especially when data belongs to his own creator, thus for offline-first and nobackend. PouchDB and Hoodie usefulness won't be affected in any way by leaving Couchapps. On the contrary they can only benefit by Couchapp features too, like security. --047d7bdca97ce8bb550515642bf7--