Headless Drupal: Delight Up Front, Data in the Back
The impending release of Drupal 8 has the Elevated Third office buzzing with anticipation.
With the release comes a feature list we could talk about for days, but one of the more interesting concepts is the idea of a headless Drupal installation. We’ll get into the finer points a little later, but, at a high level, we’re essentially talking about disconnecting Drupal’s backend from its theme layer so end users aren’t even interacting with Drupal on every page load.
Why should I care?
Before we dig into the details of what’s actually happening on a headless Drupal site, let’s take a look at a few reasons why this is such compelling evolution in Drupal development.
Let Drupal focus on what it’s really good at. When it comes down to it, Drupal can render content just fine, but where it really excels is building and maintaining complex content structures. On top of that, a customizable admin UI makes it a breeze to open those complicated content types up to non-technical users to maintain anything from a simple blog to an intricate web of related chunks of content.
Cross-platform distribution. No one wants to deal with the headache of duplicate work. It just doesn’t make good business sense to be making the same content updates across a mobile app, website and intranet. Rather than serving as just a website backend, let Drupal be the hub of all your content and push those updates to anything that can consume JSON data through a RESTful API (spoiler: just about any application should be able to make that work).
A simpler brand refresh. When all you need is a fresh look, it may not always make sense to completely revamp the architecture and backend organization of your website. Headless Drupal creates a very hard line between the front and back ends of your site, which means plugging a new display layer into that setup can end up being a much less complicated project.
Now that we’ve gone over some of the key benefits, it’s time to take a closer look at the what and how of headless Drupal. Stick around! I promise it won’t get too technical.
What is “headless” Drupal ?
Typically, a Drupal website will handle everything from retrieving content from the database to performing logic on that content to actually printing that content to a webpage that is accessible by a normal user. In a headless configuration, Drupal simply serves as a container used to manage structured content and output it to any variety of systems that can then present that content to end users. Basically, in these situations, the end user never interacts directly with Drupal, but, instead, with something like Angular, Backbone or even a native mobile app that is used to create the client-side representation of the content stored in Drupal.
So, how does headless work?
Why Drupal 8 instead of Drupal 7?
Until Drupal 8 has a stable release, we can’t really recommend it be used for a production site without careful consideration. Having said that, it will likely be the go-to solution for most Drupal developers thanks to its integration of RESTful web services out of the box. What that means is, without adding any contributed modules or custom functionality, any Drupal content can be made available via a REST API by enabling the web services modules included with Drupal core and configuring them.
That’s not to say none of this is possible with Drupal 7. In fact, a good majority of it is, it just isn’t integrated into Drupal core. To get started creating something similar in Drupal 7, it’s worth checking out the Services module or RestWS.
A word of caution
Headless Drupal is a pretty new idea that not a lot of development teams have implemented for large sites in production environments. All of the concepts are sound, but it’s always worth taking a close look at whether this is right for you to ensure unnecessary overhead isn’t being added to a project. There are a couple well-documented drawbacks to this approach that should always be considered.
Less flexible front end. What we often take for granted about Drupal’s integrated front end and templating system is its ability to incorporate changes to content architecture with little to no updates in the code. When the front end is completely disconnected from Drupal, that can become a much more complicated task involving development updating templates to consume and properly display added data.
Admin control over UI elements. Drupal has lots of great UI and layout control modules, like Context, that expose a huge amount of control over the front end to site builders and site administrators. Many of these become useless in a headless Drupal configuration where Drupal isn’t dictating the front end.
This obviously isn’t an exhaustive list, but rather situations that can easily be used to illustrate the point that careful consideration should go into a decision to use something like headless Drupal to be sure it’s the right choice.
Onward, to the future!
Headless Drupal is a fairly new concept with lots of exciting possibilities. It’s absolutely worth the time to learn more about and evaluate for your situation. We went through the technical details of that evaluation, but let’s have some fun and check how some sites are implementing this today.