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 viewpoint I love the idea of CouchApp.

   The downside is that with no server side code there are some things (like oAuth authentication) that are hard to do on the client side. At some point I'm sure I will need some server side code of some description - I guess you can then look at Node.js but would rather not at this point.

2. Using CouchDB purely as a backend solution while your pages are served from another server is also a great fit but the downside here is that the cross domain issues prevent you from easily using the built in CouchDB API.

So does anyone have a solution to one of these two downsides?

Can you somehow serve server side code (even PHP would be a win) from CouchApp or can you somehow use a separate site to serve your pages but overcome the cross domain issue?

I am really trying to keep the solution as clean (and as scalable) as possible and one of the great things about CouchDB is the super simple, super fast API so I don't really want to use a wrapper around it - unless it doesn't hinder the performance/scalability.

Your opinions are welcome.

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?