Drupal: Sometimes Headless, Never Heartless

Years ago I started asking a rhetorical question: “If you want to cut off Drupal’s head, where is Drupal’s neck?” Back in 2014 many people in the front-end community were fed up with Drupal 7. Great improvements had been made in Drupal 8, but that wouldn’t be released for another year, and the rest of the web seemed to be accelerating in the trend toward breaking up monoliths. Something drastic needed to be done. Proponents of a headless (or "decoupled") strategy wanted to replace Drupal's long-standing code and techniques for rendering front-end code with something completely different. The question of whether this architecture should be called "headless" or "decoupled" is one we've been wrestling with for some years.

Decoupled Drupal Dreams

But did we all know how to cut off Drupal’s head? Much of the discussion centered around modules. In Drupal 7 a compelling case could be made for Services, Views, Restws, Restful, and probably a few others. Having lots of options was a bad sign. As a use case matures, the community tends to consolidate with a winner. What were previously multiple image-related contrib modules in Drupal 5 became one module in Drupal 7 core. Drupal 8.0 was on the horizon with a suite of REST modules that might have fulfilled the communities decoupled Drupal dreams.

A Rude Awakening

The REST modules in Drupal 8.0 were written relatively early in the nearly five years between Drupal 7 and 8. When 8.0 finally came out and more and more people tried using the REST modules within it, they got a rude awakening. The modules had sat largely untested by real-world use cases. They seemed incomplete, sparsely documented, and unwieldy in their configurability.

In the few years since 8.0, the community has gravitated toward two modules implementing more robust standards: JSON:API and GraphQL. JSON:API is used by thousands of sites and is expected to be added to core in 8.7 next year (as a stable, non-experimental module no less). GraphQL is less mature as a Drupal module but it's cool factor in the wider web development community bodes well for its future in Drupal.

Finding the Heart Instead

I don't know if I can confidently say that the neck of Drupal has been found with JSON:API going into core. There is still a long roadmap of work that will leverage the headless paradigm. But I'm ok with that because I think JSON:API has labeled a more important part of Drupal's anatomy: the heart. The Drupal.org documentation comparing JSON:API and the Core REST module says "Core's REST module allows for anything (any format, any logic, any HTTP method) and extreme configurability. Powerful but complex and hence relatively brittle. JSON:API focuses on exposing Drupal's biggest strength (entities/data modeling) in a coherent manner. Simple yet sufficiently powerful for most use cases." In other words, Drupal's data modeling is its heart.

It is not an accident that JSON:API is taking a starkly different approach from the REST module. All over the web landscape monoliths are being broken up. To adapt, software needs to put its best feature forward and allow the rest to be stripped away and provided by other tools. One of JSON:API's maintainers, Wim Leers, has wisely decided that Drupal's tendency to encourage complex configuration is not worth keeping. In fact, he makes a point of releasing modules like BigPipe and CDN with minimal or no configurability when possible.

Follow Your Heart

Knowing where Drupal's heart is can help you decide if Drupal is right for you. Use Drupal if you have multiple interrelated types of well-defined content. With a well-planned data model your Drupal site will be able to serve information in multiple contexts through JSON:API, GraphQL, or whatever comes next. Send your Drupal content to Alexa, GatsbyJS, and maybe even an internet-connected big-mouth bass.