If you’re keeping up to date with trends in web development, a “headless CMS”, whether Drupal, Contentful, etc., is a term that has certainly caught your attention.
However, we’re not all techies, or web developers and that’s why it is important to explain in more general terms what “headless” means and explore how and when to apply it to websites, apps, etc.
Let’s break it down first...
What is a “headless CMS”? A headless CMS is a content management system that gives you the possibility to separate what the end user sees - the frontend - from the database where all the content is created and stored - the backend.
The “head” relates to where your content ends up, and the “body” is where your content is stored and authored. The idea is that you don’t have to stick to the “head” of a particular CMS - you get to pick and choose which heads (outputs) you send your content to and how it will be presented.
So, if the frontend and backend are built in different technologies, how does it work? For example, if Drupal serves as the backend for your website, the frontend technology communicates with Drupal via an API - an Application Programming Interface. The API is the software that allows two applications to talk to each other and fulfill the necessary data exchange.
This removes the "head" from Drupal and decouples it from CMS's control. Hence, the term “headless”.
Is Headless CMS the perfect solution?
Headless CMS (aka decoupled) sounds great in theory and can provide many advantages, but there are also some potential downsides you should look at.
On one hand, by making Drupal "headless”, you’ll need to recreate an authentication method and reinvent other features, but it provides all the content for other applications or sites to consume and style on their own.
The headless strategy has, in fact, tremendous upsides:
:: “Create Once, Publish Everywhere” - your website can send its data to any application you need. Content is reused and you can significantly increase your multi-channel presence (mobile applications, IoT, kiosk displays, etc.)
:: You can add incredible interactive features and visuals that other technologies offer (Angular, React, Vue, etc.). When used together, such different platforms multiply each other’s benefits. The possibilities of using any existing frontend technology are endless.
:: Website performance can be significantly improved. This is because the front-end frameworks are fast and the decoupled architecture takes the load off the website’s rendering system.
:: Unlimited opportunities in creating real-time features (live e-commerce cart updates, live notifications, news updates, and much more).
:: Usability of your website can rise sky high, which will result in increased conversions
:: Flexibility and diversification of the development team. For instance, Drupal experts are very hard to come by. By separating the backend and frontend technologies, you’re able to hand off part of the development process to talent that is more available, and expect a faster delivery.
:: Reduced costs of redesigns and independent upgrades. Once you have decoupled your site, you could launch a brand new design without making any back-end changes, and vice versa.
:: There is a clear separation of interests between the backend application and the frontend presentation.
:: Components and code are reusable and therefore you’re able to reduce time and costs.
:: Headless deploys quickly, consistently delivering faster time to market and value and therefore
Headless CMS has evolved out of traditional, coupled monolithic structures: if we consider monolithic Drupal, it’s a complete solution where backend and frontend are intrinsically linked and optimized for SEO and accessibility. It also includes APIs (REST e Json) in its core version.
The traditional Drupal CMS, gives you, out of the box, the ability to define, manage and display simple content, like a content type with a title, body, author and image, and complex content like a recurring event with registrations and limited seat capacity. When you separate the head, how something 'looks' from how content is managed, that kind of out of the box functionality is lost or limited.
Other Headless challenges include:
:: Increased technical complexity. A decoupled system becomes a host of systems as a whole and figuring out a bug becomes more complicated.
:: High upfront development costs. It costs considerably more to decouple than to build a traditional site as decoupling requires additional infrastructure and recreating solutions provided by traditional CMS, for instance recreating authentication systems.
:: Increased task difficulty. Some tasks are particularly tricky in a decoupled environment, like a content preview before publishing. It could look completely different than the webpage, and you can’t preview it because you can’t be sure how it will be used.
:: Less page control. Editors are no longer able to control the layout, the order of content elements ,etc. Content is placed by the apps that consume it, not by editors. There are ways to give editors tools to indicate preferences, and ways to design front ends to respect those preferences, but it adds complexity to the system.
When is Headless the right choice?
You can evaluate that decision by asking a few questions:
Are your backend and frontend needs separate?
If your CMS doesn’t provide for the complete interactive frontend experience, for example, combining a modern front-end by using React or Angular and a very proficient Drupal backend makes sense.
Are you ok with the financial implications of a headless CMS?
Headless, or decoupling, becomes more expensive, since features that would have been free would need to be built from scratch by the development team, more infrastructure would be needed, as well as a bigger team.
Do you have the right team?
Ok, the need is there, and so is the budget, but you also have to make sure you have a skilled and experienced team - actually, two teams - to take on a decoupled project, working in sync, to make it a success.
Do you have to cater to different channels?
Create once and publish everywhere has become synonymous with headless CMS. If your content has to feed various publishing platforms, then a decoupled application could make sense.
Are you ok with more complexity?
Headless CMS requires a change in the mindset of developers and content editors. It is a more complex system than a traditional CMS. A simple task like previewing content before publishing it would no longer be an available option. Also, having a web of systems can turn into a nightmare if you have to fix a broken link, but don’t know where to look for the problem.
Wrapping your head around Headless
If your current CMS option accomplishes what you need, you might have to re-think the decision of decoupling.
With the need to make the same content available at once to multiple audiences, simultaneously across several platforms and improving digital experiences, a Headless CMS is always going to be the right choice as long as you know that you can and will overcome its drawbacks.