It’s no secret that I am a fan of Drupal for its plumbing that yields out-of-the-box stability, security, and configurability. Using Drupal and an assortment of contributed modules, it’s relatively easy to quickly create most any type of website.
Before learning of Drupal 8’s RESTful services, I questioned if there were any natural scenarios where Drupal could integrate with a MEAN stack-based application. One idea which I ended up modeling was using Drupal for a pure management console of data in a Mongo document-oriented database.
Example: Job Board
Drupal has the notion of Content Types that define and separate…well, logical types of content on the site, including the fields that can be filled in for each content entry (called nodes in Drupal). For instance, consider a Job content type that could be a basis for creating a job board. Fields for a Job might include the position title, job description, educational requirements, start date, and so on. With the content type defined in Drupal, any new Job nodes are stored in Drupal’s database.
Let’s say we want to manage (create, edit, delete) Job nodes in Drupal (taking advantage of Drupal’s account creation, permissions, security), but allow a light-weight mobile application to access and display the job listings. Ideally the data is accessed by the mobile app via JSON queries, and for this example let’s say the mobile app is written in Ionic (and Angular-based framework), and the server is written in Javascript running on Node JS.
From MySQL to MongoDB
Drupal uses a relational database like MySQL or PostgreSQL to store ALL of its data, including content, configuration, users, permisisons, etc. Instead of developing the Node server to access Job content from Drupal’s MySQL database, I found it much easier to extract the Job data out of MySQL and into a Mongo database for access by the Node server. This is done in real time by Drupal as Job content is created, updated, and deleted.
It is fairly easy to one-way synchronize (from Drupal to MongoDB) the job listings by writing a Drupal module. Using the Drupal hooks to trigger when Job content is created, updated, or deleted, the Drupal module executed the same operation on the Mongo database’s collection of job listings. In the MongoDB document, I captured the Drupal field data as well as some metadata, including the Drupal node ID and creation date. Then later when the Job content in Drupal is updated or deleted, the node ID could be searched in the MongoDB collection to perform the same operation.
Granted, the flow of data is one-way (from Drupal to MongoDB), and it assumes the mobile app will not be modifying the Job postings and synchronizing those changes back to Drupal. However, if two-way data flow is desired, either a call-back mechanism or polling (via Drupal’s cron hook) could synchronize new data back to the Drupal database.
Why?
While developing this example, I realized some good reasons why this implementation is interesting:
-
CMSs like Drupal really provide two types of content services: (a) content management, and (b) content viewing. The same website/CMS code base and infrastructure supports both interactions. However, for many site implementations, the predominant type of user interaction is skewed heaviliy in favor of content viewing. It turns out that a sizable amount of code has to be executed for every interaction on the site, even if it’s just to view the data. This can be a non-trivial amount of overhead, especially for high-traffic sites (even with various levels of caching). Once the content is created, if the audience who consumes it does not need to modify it, I assert it’s hard to beat the transfer time, data size, and server-side processing power required to process JSON/MongoDB query via a RESTful Node server.
-
Drupal excels at content creation and management (not to mention user management, security, etc.). If you’re developing a primarily mobile application (even without user-facing website), you can leverage the vast number of contributed Drupal modules that support content creation (e.g. RSS import) for your mobile application without a great deal of development effort. Then you can focus your time developing your mobile app instead of developing the mechanism and interface for getting external content into your database.