Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of geddes.jonathan@gmail.com
 designates 209.85.215.52 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAMWZAjnkpfRXxJSpS96V8s9Btg0VfhYxbP2xMjZy7UTmWx99Yw@mail.gmail.com>
References: <8B350540-5545-4983-9413-68BB920ABC67@supercoders.com.au>
	<CAMWZAjnkpfRXxJSpS96V8s9Btg0VfhYxbP2xMjZy7UTmWx99Yw@mail.gmail.com>
Date: Mon, 11 Jul 2011 19:52:55 -0600
Message-ID: 
 <CAFnw-01D_eLMTrCZDzykPP7vFHsw2YhvWaZ=hPngryirorL4WA@mail.gmail.com>
Subject: Re: Building substantial "pure" 2 tier CouchApps - feasible?
From: Jonathan Geddes <geddes.jonathan@gmail.com>
To: user@couchdb.apache.org
Content-Type: multipart/alternative; boundary=90e6ba6153aaff129b04a7d58e26

--90e6ba6153aaff129b04a7d58e26
Content-Type: text/plain; charset=ISO-8859-1

I think the "pure" 2 layer approach is not going to be feasible, to be
honest with you. I think a more realistic goal is what some have been
calling a 2.1 tier architecture. The 2.1 tier architecture is simply the 2
layers plus some simple utilities *behind* couchdb. What I mean by 'behind'
is that the client doesn't interface directly with the utilities, but with
couchdb directly, just like the 'pure' architechture. The utilities behind
couchdb either:

a) listen on the _changes api for certain events and do some processing in
the db (wait for image uploads and then crop them and put them back in the
database, for example)
b) accept requests that come in through couchdb's reverse proxy capabilities
[0] and perform something that is beyond the scope of couchdb (large joins
over several queries, etc).
c) run as an "external process" [2].

In cases a and b, you can use "external os processes"[2] to make sure that
the other parts of the system are always running (if they crash, couch will
start them again!). In case c, a new process is spawned for each request, so
this can be slow.

The nice thing about this approach is that you can start slow with a simple
couchapp, but know that if needed, your architecture can grow
to accommodate essentially any requirements (at the cost of some of the
deployment flexibility of a chouchapp).

[0]
https://github.com/apache/couchdb/commit/11469d902b15145d361f9f7ec66a09ac3d04757c
[1] http://wiki.apache.org/couchdb/ExternalProcesses
[2]
https://github.com/apache/couchdb/commit/c8785113522b8486fab0ba53f2043d94e9b1507f

disclaimer: I'm currently exploring the effectiveness of this approach, but
I've never seen it to be effective from start to finish! And my app still
hasn't grown beyond the simple couchapp model (no extra utilities yet). It's
surprising how much fits into the couchapp model!

HTH

--Jonathan

On Mon, Jul 11, 2011 at 7:18 PM, Marcello Nuccio
<marcello.nuccio@gmail.com>wrote:

> I am building a pure couchapp to:
>  - insert the orders of the clients;
>  - insert the modifications requested by the clients;
>  - assign the work to the laboratories;
>  - track the warehouse.
>  - etc.
>
> Not very big, but quite complex because I have many document types and
> I must exchange data with lot of legacy systems.
>
> It is an hard work if you are used to RDMS. The most challenging problems
> are:
>  - how to model the data to keep the couchapp simple, efficient, and
> easily interoperable with other system?
>  - access control: in CouchDB is a brand new world. Everything you
> already know on access control is almost useless with CouchDB.
>  - you will need to write some external utility to do some tasks, not
> only for maintenance.
>
> just my 2cents...
>
> Marcello
>
> 2011/7/12 Andrew Stuart (SuperCoders) <andrew.stuart@supercoders.com.au>:
> > I'd like to build a rather substantial application, it would be nice to
> > build it as a pure 2 tier CouchApp.
> >
> > How practical is this really?  Does anyone have experience building
> anything
> > big in this way?  Or are 2 tier CouchApps really only effective for small
> > stuff?
> >
> > I understand that it very much depends on what the app does, but I'm
> trying
> > to get a general sense of it.
> >
> > If pure 2 tier CouchDB apps is an impractical goal then we'll design the
> > architecture from the beginning as a 3 tier app and whack in some sort of
> > server.
> >
> > as
> >
>

--90e6ba6153aaff129b04a7d58e26--