Aspects of Drupal
In the previous part of this series, we briefly introduced Drupal from the perspective of an enterprise architect. We looked at the underlying language and framework and where Drupal sits in the product/framework spectrum and discovered that it was a kind of hybrid of product and higher level framework built on top of widely used PHP and Javascript frameworks.
In this part, let’s take a deeper dive into programming style and some aspects which cut across the system.
Hierarchical pattern and hooks
In contrast with many other server-based web application frameworks which follow the web MVC pattern popularised by Rails, Drupal uses a hierarchical variant called Presentation-Abstraction-Control (PAC - most widely used in air traffic control systems), which is largely indistinguishable from the Hierarchical model–view–controller (HMVC) pattern.
Note: Wikipedia: Hierarchical model–view–controller (HMVC) is a software architectural pattern, a variation of model–view–controller (MVC) similar to presentation–abstraction–control (PAC), that was published in 2000 in an article in JavaWorld Magazine, the authors apparently unaware of PAC which was published 13 years earlier.
In this variant, the system is composed of triads, each containing its own data-logic-presentation layers. For Drupal, the basic building block is the module and each module will be responsible for its own data, logic, and presentation. (Thus a Drupal module represents a PAC triad.)
As you would expect, the framework supports communication between these modules and this is done by the use of event-based hooks fired during code execution rather than via a single central controller (as found in web MVC). With this capability, we are able to create new modules which react to system events and alter system behaviour without touching existing code. For example, we might create a new module to send out an email or update a CRM system when a user changes their contact details. As long as those hooks are available, no existing code needs to be changed and we can just layer on our additional functionality.
This simple approach to layering system capabilities is at the heart of how Drupal has developed so much power and diversity and has evolved from a simple bulletin board to a digital experience platform which competes with the largest enterprise systems.
Many of the most widely used modules are highly generic building blocks in themselves, spawning their own small ecosystems of extending modules as they are applied to more use cases. For example, the Views module (a form-based query builder and renderer) has over 800 associated modules, providing everything from carousels and slideshows, to forms, to incoming and outgoing data feeds.
Monolithic architecture in D7 and earlier
Another key point to understand about Drupal that we have touched on is that it has a monolithic architecture in all versions up to and including Drupal 7.
It is a full stack platform which covers a very wide surface area including content management, user management and permissioning, web applications, publishing and presentation, commerce, and back-end integration.
Whilst this is great for SMEs and represents an opportunity for simplifying and streamlining technology, many enterprise projects require a high degree of decoupling for these kinds of functionality. The usual way to achieve this has been through Drupal’s contributed Services module (which provides read-write web service interfaces to Drupal’s functionality).
In response to these kind of requirements and the arrival of mobile, Drupal 8 has been designed to allow a far greater degree of decoupling. This has been achieved by the inclusion of services in core as well as adoption of the PSR standard which allows interoperability between PHP frameworks and libraries (for example we could in principle swap out the rendering component).
It should be recognised that Drupal 8 still provides a full-stack platform by default and that decoupling will still require fairly deep expertise, but this is becoming a more well-travelled and hence better designed path. The influence of microservices is increasingly apparent and it is expected that Drupal will start to play better with this kind of architectural approach.
Note http://martinfowler.com/articles/microservices.html
The term "microservice" was discussed at a workshop of software architects near Venice in May, 2011 to describe what the participants saw as a common architectural style that many of them had been recently exploring. In May 2012, the same group decided on "microservices" as the most appropriate name.
The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.
These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.
Content services orientation
At a functional level, an aspect of Drupal which often confuses newcomers is what can be described as its 'content services' approach to managing and publishing content.
Many CMSs revolve around the concept of an entire page as their basic building block, often arranged within a hierarchical tree of folders. By contrast, Drupal’s ‘atomic unit’ is the entity, which is typically a piece of content.
The key difference here is that Drupal’s pieces of content can be used in article pages, side panels, listings, data feeds and so on. Pages are then composed, drawing upon these content fragments. This actually models more closely the kind of content architecture we find on most websites. Take a typical news site for example - it will have landing pages, listings, articles with related content, and so on. These pages will be made up of elements which are a combination of hand-picked items chosen by editorial staff, and those automatically selected by a set of rules (e.g. related articles, most read, latest news).
