CouchDb, PHP and the offline Web
For a while I’ve been kicking around an idea of how to integrate CouchDb with PHP. PHP is a great fit for CouchDb, both the development toolsets and runtime model should integrate nicely, and CouchDb can teach PHP a new trick: web apps that can work in a offline mode.
The Integration Model
The way PHP works, applications are typically just a directory of PHP/HTML files that interact with a database, usually MySQL. Also in the directory are various resource files needed by the application (.css, .jpg, .js, etc). These application files can be zipped up - code, HTML, images and all - into a single archive file and then redeployed on another server.
To integrate CouchDb with PHP, the same model is employed, with code in PHP files interacting with a CouchDb instance instead of a MySQL instance. The Couch/PHP application and resource files can be then zipped up into a single file, just like before.
With CouchDb, the PHP application zip file can be stored in the application database as an attachment to a design element. The design element can also contain the computed table formulas and other resources necessary for the app at runtime. A whole PHP/CouchDb application can be stored in a single design element.
These design elements are just a special documents that will replicate around just like normal application documents. Then, a small bit of code on the CouchDb/PHP server will monitor when CouchDb design elements are updated. When they are, it retrieves the compressed files and unzips the PHP application into a temporary directory on the PHP server. These files are served up like a regular PHP application.
The unzipped PHP application code will then interact with CouchDb normally: viewing, adding, updating documents and records, etc.
Replicate Applications, Not Just Data
Combine this application and distribution model with a locally installable, browser integrated PHP/CouchDb application host, then end users can easily take full PHP web applications offline with them.
These offline applications run the same PHP application code and access the same data (or a subset of the data) as the online hosts. They can browse, edit, and update the data in CouchDb just like they were connected, using the same browser interface.
Then when they reconnect to the network, they click a button and replicate all their changes back to the server and everyone else’s changes back down locally. When the PHP application design is updated, the user will automatically get the updated PHP files during replication, where they again will be unzipped and deployed on the local machine.
The work to build the infrastructure for this should be relatively small in scope. A PHP server side package manager is necessary to unpack application files to the proper places and configure them to be served up. Much bigger work items are thing like a local installer and browser integration necessary for end user deployment.
The beauty of this system is it is possible to use the whole PHP development stack and extend it to a new storage/distribution model. Development of PHP/CouchDb applications should be almost completely compatible tool-wise with regular PHP tools.
So for example the development/debug process shouldn’t have to change, just the production deployment. During the development and update-debug coding cycle it wouldn’t be necessary to deploy the zipped application files to the Couch server. Instead you keep all files wherever is handy during normal development and testing while updating the design document’s computed table formulas, etc as necessary in the test database. When ready the PHP application files can then be packaged and stored in the Couch database, where they are automatically deployed by the application server.
One of the most interesting things about using PHP is the possibility of reusing popular free PHP/MySQL applications and porting them over to CouchDb. This can give new life and demand to many PHP application businesses already use but cannot access offline.
A couch being jumped on by actor Tom Cruise
One downside to using PHP is it supposedly has configuration problems, where apparently much of the core PHP behavior is tweakable in a server wide ini-file, make compatibility issues from server to server a problem for applications. I’m not experienced enough in PHP to know how bad this problem really is, but I’ve seen more than one complaint about it.
This application model could work with Ruby or Python or whatever instead of PHP. But the existing PHP application architecture is such a great fit I’m not sure another language and framework can be as easily and completely integrated. PHP may not have the meta-programming sex appeal of Ruby and Python, but it’s damn productive for web development and its tools are already compatible.
However, the development of this PHP system wouldn’t preclude other languages. It would just be the first language/framework integrated. It’s perfectly possible to simultaneously integrate with any number of web hosts and languages in the same CouchDb database. Like MySQL, CouchDb is language agnostic at its core.
Ok, I hope I've explained this clearly for the tech heads out there. I need to make some pretty diagrams of a complete system and web application to help get the ideas across better. Any feedback on this idea is welcome, especially if you know why it's fatally flawed, technically or otherwise.
Posted October 8, 2006 12:02 PM