Skip to main content

Latest Entries

In the last couple of years I have been involved with a lot projects all with the same type of scenario, there is a server housing a content management system or a database, a remote mobile application that reads data from the server,  and usually a web application for anonymous and authenticated web traffic.  Projects like this are extremely interesting, but can get very complicated in a hurry as the project evolves and features are added on either the web side or the mobile application side.

In part one of this post I explained the need to have a content management system detached from the web service.  In part two of this post I explained how to sync the data from Drupal to MongoDB and sync it in a way that left Node.js to just read the data and serve it.  So now in part three of this post the only thing left to do is build the web service to serve the read-only data on.

In part one of this post I explained the need to have a content management system that was detached from the web service.  In explaining this need I also described how I am going to use Drupal for the CMS, MongoDB for the secondary data store, and Node.js as the web service platform.  Now it is time time for the fun part, setting up our integration!  In this post I will demonstrate how to take your existing Drupal CMS and integrate it with MongoDB to take the first step in building out data for your web service.

Over the last couple of months I have been struggling with an idea that involved using Drupal as the content management system and the web service for an application that I am currently building in iOS and Android.  The reason I am struggling with this idea is because I am using Drupal 7 and Drupal 7 was not intended to serve data to a web service, but rather to serve web pages.

When dealing with a high traffic web site it is often nice to implement some sort of caching mechanism or load balancer into your site architecture.  Varnish cache is often a popular caching daemon used to serve cached web pages.  Varnish in most cases also acts as a reverse proxy and detects values in the header of the request to delegate traffic in a specific way.  One example of this might be to route all traffic to slave servers, or to route all traffic to a failover server in a case of an emergency.