Home/ Questions/Q 3349532
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-18T01:40:34+00:00

I have been playing with CouchDB and CouchApp for a little while now. I

  • 0

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.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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:

    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.

    • 0