What is Headless Drupal?

The goal of this article is to break down what “headless Drupal” (or “fully decoupled Drupal”) is, and what it means for your business.

In short, the phrase “headless Drupal” applies to a site with a completely separate front end framework from the Drupal backend storing the data. The front end framework is responsible for what to display, and requests data from Drupal as needed. This removes the “head” from Drupal and decouples it from CMS’s control.

Where did headless Drupal come from?

As the web has evolved, the desire to control and display content across different devices and platforms has increased. Early on this meant connecting website data to display on native phone applications, or communicating with enterprise business hardware and software.

With the advent of JavaScript frontend frameworks like Angular, Ember and React, the void for “headless” (or “decoupled”) content management systems has grown. During Drupal 7’s tenure, the community made contributions to fill the void left by new frontend frameworks.

This decentralizing of content display motivated the industry to create storage for holding and managing content. When Drupal 8 was released, this ability was built into core. Drupal offered a progressive solution to the problem of decentralized content.

What does this have to do with Drupal?

Traditionally, Drupal’s strength has been its ability to define, manage and display content. Drupal is helpful when creating a simple ‘article’ content type with a title, body, author and image and can also handle some something more complicated, like a recurring event with registrations, limited seat capacity and attendance tracking.

Out of the box, Drupal gives you the ability to revise, preview, tag, and relate content. Additional publishing features often include revision history, authorship workflows, and media libraries.

So by making Drupal “headless” we really mean that the Drupal site isn’t styled for an end user, but it provides all the content for other applications or sites to consume and style on their own. This functionality is a powerful addition to Drupal 8 core.

Sounds great, let’s do it!

This is where it gets complicated, and if you just wanted to find out what ‘Headless Drupal’ was, this is where you should probably stop.

When should you use headless Drupal?

A fully decoupled approach sounds great in theory and can provide tremendous upside for the right type of application, but it certainly isn’t a one-size fit all model. Because you are separating responsibilities so decisively, gray areas get… grayer?

Since headless Drupal separates how something ‘looks’ from how content is managed, certain out of the box Drupal functionality is lost or inhibited. Decoupled apps can’t generally ‘preview’ unpublished content, layout control becomes tricky, and apps can compete for control of ‘routing’ the user to display the correct content.

Fully decoupled often implies that the frontend app is taking responsibility for the initial request. From there, responsibility for business logic must be split out, and sometimes duplicated, between applications.

These issues are not a ‘Drupal’ issue so much as a decoupling issue. If the responsibility for layout and content storage are in your data source, and your data display also implies layout, then it’s important to determine which has authority.

Consider these things before starting.

These challenges have bred a number of other architectural philosophies, such as ‘Progressively Decoupling’, which looks to sort responsibilities and maximize benefits of using Drupal while still providing decoupled components and services to the front end.

It’s not so much which model is right, or wrong, but rather which fits the given need. It’s important that you sort out and identify early on how your applications will interact, before picking an approach and having the right agency partner certainly helps.

The post What is Headless Drupal? appeared first on Speckyboy Design Magazine.