CouchApp without Server side or CouchDB backend with xdomain issues?

Question

I have been playing with CouchDB and CouchApp for a little while now. I am planning on using it for a new web site project I\'m working on.

1. From a scalability vi

Answer 1

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:

1. 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).
2. 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.
3. 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.

Answer 2

Excellent answer from BigBlueHat, but I have one more more possible option to add:

Overcome the cross-domain problem, thereby allowing you to serve pages from any sort of web server, and also allowing the browser to interact directly with CouchDB ( which can be on another server ).

The cross-domain restriction, as enforced by browsers, is not that hard to get around. The 2 main methods that I know of are: JSONP and CORS.

JSONP disguises each request as "script" request ( as script requests are exempt from the cross-domain rule). It only works for GET, not POST or PUT or anything else. You can do it with jQuery.

CORS is "Cross Origin Resource Sharing", and it is simply a special HTTP Header that must be implemented on the server ( couchdb in this case ), which tells the browser that it's OK -- it doesn't mind serving requests that come from another domain. I have tested this, and it does work, but there might be security issues -- I am not sure.

So...I don't know whether it's a good idea, but it is technically possible to ( at least partially ) overcome the cross-domain restriction with CouchDB. Has anyone ever built a system using this type of setup?