Headless content management systems (CMS) have been around for a few years now, and have been rapidly adopted as a way to build more sophisticated front-end experiences across many different devices while reusing the backend content management.
Drupal, in particular, has led the way focusing on the continued development of its headless capabilities. In this post, we’ll explain what a headless CMS is, how it’s used, who’s using it, and its potential drawbacks and benefits.
What is Drupal’s Headless CMS?
Think of a Drupal CMS divided into two parts. On one side is the back-end which includes content, data, and anything else you use to directly manage your website. This is the side site visitors never see. On the other side is the front end, which your user does see and interacts with.
Drupal CMS provides an administrative back-end capable of making changes that display on the front end of your website in HTML. This is essentially what all CMS platforms do: provide an administrative suite to non-technical website managers.
The idea of a headless Drupal CMS is you keep using the administrative back end, but the front end and presentation can take many forms. For example, a javascript framework like React might be used instead to present the front end.
What is Drupal’s Headless CMS used for?
The benefit of Drupal’s headless CMS is that by disconnecting the front end from the backend, you can still take advantage of the backend’s content editing and data-storing capabilities while having content styled and served by your choice of application or framework.
A headless CMS is great for building an incredibly custom UX, mobile apps, or a website capable of interacting with virtual assistants (like Alexa).
What are the benefits of a headless CMS?
- Historically, content management systems output HTML for websites. With a CMS that can output many content formats from XML, JSON, or over API calls. It means your user experience can be unique and better serve your business—it's no longer all about web pages.
- Increased page load speeds. By separating the two, your website is no longer responsible for delivering everything from the front end and back end together at the same time. For example, it might serve content to a mobile application that stores it and present it.
- A headless content management system is then mainly responsible for structuring and managing content so it can be reused across more than just a website. It could be a reuse of content across dozens of sites, mobile apps, IoT devices, or anything you want. It provides a great approach for centralizing content management for reuse.
Are there any disadvantages?
Imagine a system where content is input by an editor, and that content is consumed and presented via a third-party built Android application. In a "web-only" world, you have good control over page layouts and the appearance of what you produce on your website.
You can still produce content in Drupal’s backend, but the page layout, user navigation, and page creation capabilities might be managed in a UX you don't control (this also might be viewed as a major advantage).
Because the front end has been redefined, how your content is styled on the page is entirely dependent on what your developers have created. Making adjustments to design elements and layouts on your website, mobile app, or browser app will require front-end developers.
What Drupal’s Headless CMS means for the future
Drupal has always been easy to customize, upgrade, and manage, not to mention it has a strong security track record and is supported by a thriving community. Drupal has always been known as one of the most flexible platforms available.
Curious to learn more? Here's how we can assist with Drupal website development.
Drupal strives to be “future-proof,” to keep up with changing internet technology in order to stay relevant for the people and businesses who rely on it. Similar to Drupal's modular structure and open-source build which allow administrators to easily integrate it with APIs, Drupal’s headless CMS is a move forward for clients whose end goal may not be an HTML website.
For more reading on the API-first approach Drupal has been taking since 2012, go straight to the source: Dries Blog has some great posts on all of the steps they’ve taken to deliver a CMS that can support any experience.