Tag: development

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:

1. 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.

2. 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.

Over the past fifteen years, I have needed to upgrade my computers less and less. In the late ’90s through early 2000’s, every couple years my motherboard/CPU/memory were so horribly out of date that the latest software updates almost begged me to upgrade. However, I built my last PC over five years ago (ASUS board, quad-core AMD processor @ 2.4GHz, 4GB memory), and it continues to steam along through every OS I have installed. In fact, even single or dual core PC’s that date back to 2006 still have plenty of life in them. The reason is simple: computers have steadily become fast enough for the basic applications we use daily — email, web browsing, and office applications.

Of course, back in the mid-2000’s, there was no such prevalence of the cloud, much less any type of browser-based applications that lived within it. Applications and their data were stored on the PC, and thus required sufficient local horsepower and storage. Jump ahead to 2014 — it’s a very different story. Dropbox or Google Drive synchronize your data into the cloud, and Google’s suite of office applications are good enough for most day to day activities. With the web browser becoming the most-used application, the requirements on a PC that is already fast enough are minimal: you can conceivably get by in life with only a web browser. In fact, the bulkiest “application” that slows down the machine could be considered the operating system itself! (Looking at you, Microsoft.)

This is the premise of Chromebooks or more recent Chromeboxes: design hardware and the OS to support a web browser in which the user does everything, and replace the standard desktop or laptop for a fraction of the cost. Companies like Google, Samsung, and ASUS are starting to sell these systems based on Chrome OS, a Linux-based variant. However, if you already have an older PC laying around, why shell out more money when you can repurpose it as a veritable Chromebox.

Peppermint is a Linux distribution that was developed under the same premise as Chrome OS, and is freely available. I discovered Peppermint a year ago when switching to Linux Mint as my distribution of choice. Mint is based on Ubuntu (itself stemming from Debian Linux), and in my opinion creates a more familiar and user-friendly desktop look and feel than Ubuntu. Peppermint, like Mint, produces a similar, familiar user experience, but aims at minimizing its own footprint so it run speedily on low-memory, lower-performance (older) systems. While Peppermint bundles some basic applications (including Dropbox), you could argue its primary app is Chromium, the open-source web browser project behind Google Chrome. More applications can be installed, but the baseline configuration is perfect for targeting a system that uses the cloud for productivity (e.g. Google’s office applications). In short, Peppermint has become my favorite go-to operating system, especially when breathing new life back into 6-8 year old hardware.