Because CouchDB uses an HTTP-based API there are several ways to "mix and match" server-side code (node.js, PHP, etc) with your CouchApp.
I break the options down into three categories:
- First, a 2 Tier Architecture is what you have now: Browser + CouchApp served from CouchDB. It's a great solution for apps that only need what the browser and CouchDB can offer, but you'll need another tier as soon as you hit the need to send e-mail, resize images, or get data from another database that doesn't have an HTTP API (MySQL, MongoDB, etc).
- Next, is the 3 Tier Architecture: Browser + Apache/PHP (or similar stack) + CouchDB. This is the more "traditional" option (i.e., LAMP). This is fine for gradually migrating to CouchDB, but long term, it can get cumbersome having to route everything through a second HTTP server (as a proxy, perhaps) or server-side scripting language like PHP.
- Last, and my favorite, is the 2.5 Tier Architecture: Browser + CouchDB + externals or _changes feed-based "actions." In this case, PHP (or similar) acts as a service provider of sorts to CouchDB. Actions can be triggered by either having PHP watch the _changes feed for certain types of documents and their changes (i.e., image upload, email message document), or CouchDB can be setup to "ping" an _external handler to do further processing on the document or its attachments. This is essentially how couchdb-lucene works by watching for updates and taking action on them as they happen or at regular intervals.
You can find out more about the _changes feed and _external handlers below:
- _changes feed: http://guide.couchdb.org/draft/notifications.html
- _external handlers: http://wiki.apache.org/couchdb/ExternalProcesses
For what its worth, I'll be discussing these three options this coming Wednesday in a PHP and CouchDB Webcast. Your questions would be a valuable addition to the discussion at the end of the webcast.
I'd love to know how your CouchApp turns out, and how you solve the problems you mentioned above.