Just to not confuse things, "external processes" isn't the same as a "view server", all couchdb does with a external process is forward the query parameters to and the output from the proces. In that a way it doesn't really matter much if you put the service in front or behind couchdb Only reason I would put it behind is to avoid having to write the http request handling code to communicate with the client, because couch handles that for you and all I have to do is read from STDIN.
On Mon, Aug 24, 2009 at 7:54 PM, Adam Jacob<[email protected]> wrote: > On Mon, Aug 24, 2009 at 12:14 AM, Tom Sante<[email protected]> wrote: >> If I'm combining thousands or millions of rows into one result set I >> want my server to handle it and not some hacked together javascript on >> the client side. >> It's gonna be a lot faster, especially with some caching to avoid >> repeating the same unnecessary work. Same reason you don't just send a >> client app all docs and let it handle the view generation. The point >> is, you have your database server handling the data and your client >> side app handling client side stuff, and not mix things up. > > That makes sense - if the data set is large enough, you may not want > to do all the shipping that way. I might still build a separate query > service in front of CouchDB, rather than a view server behind it, but > that's just me. :) > > Adam > > -- > Opscode, Inc. > Adam Jacob, CTO > T: (206) 508-4759 E: [email protected] >
