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 <[email protected]>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) <[email protected]>: > > 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 > > >
