[Updated with Headless CMS Buyer’s Guide link and my commentary]
I’m about to embark on a new website re-design / rebuild. We’ve decided to move to a headless CMS (content management system) for this project. If you’re not too familiar with the headless CMS approach you can learn more here and here. Also, headless and decoupled CMS terminology is often used simultaneously or interchangeably. It can be confusing and I found this article to be helpful in distinguishing the two.
One of the reasons for our decision to move to a headless CMS is so we can effectively ship content across multiple applications (Multiple websites, mobile apps etc.) using our own API. We’re planning to use React as our framework to render the front-end of our websites although there are many other popular options like Angular, Ember and Backbone. The existing site runs on Drupal and we haven’t yet decided on the CMS we’re going to use for the new one.
Most of my experience is working with Drupal and WordPress. This is my first headless CMS project so I didn’t have a good grasp of the many nuanced methods and decisions that need to be made. While the technical aspects are numerous, my thoughts here are through the lens of a project / production manager and how choosing a headless system will affect the ongoing content creation of the site after it launches. After doing research regarding headless CMS websites it’s clear that we are still in the early days and there are many different schools of thought on implementation methods and tools to use.
Ch-Ch Changes
With so many different approaches it’s important to understand that a headless website will most likely affect the existing functionality that is available to editors and admins of the website. Making sure you gather great requirements upfront with an understanding on how the execution of existing production tasks may change based on user roles (editor vs. developer) is important to understand up front.
Since the CMS will no longer render your pages you have many new decisions to make. One example in our case was to identify many of the site elements that are likely to remain static or change very infrequently and having those elements hard-coded on the front-end. Previously these could be easily changed by an admin through the CMS but now will be changed by editing code on the front-end. For example we’ve determined that the menu navigation will be hard-coded. Currently we manage that through the CMS and a site admin can easily add or change the navigation. In the future it will require a developer to update the related code.
This shift in the responsibility of roles is an extremely important consideration based on the existing staff that works on the website. You may need to re-balance by adding (or training existing) people to be on your development team for the website content production process.
Understanding these subtle changes and what parts of the site can be managed by the CMS vs. what a developer will need to update is important as there could be huge implications to how you manage the on-going content production of the site. Getting these nailed for a headless project and having them documented and approved are crucial ahead making any architectural decisions. If you decide to make changes later down the line, they can have a much greater impact than with a traditional CMS website where you have so much functionality exposed to admins or added easily with a module or plugin.
Helpful Articles to Read
We’re still in our planning process and I’m sure there are many more discoveries as we get closer to kicking off this project. Below I have provided a few articles I found that help illustrate the considerations necessary when researching headless website implementations. Note that some of these articles are CMS specific but the issues are universal regardless of which CMS you choose to use.
Progressively Headless Drupal Approaches
- Notable Quote: “Conclusion: All in all, these diverse approaches to progressively headless Drupal have one thing in common: their close attention to each use cases specific requirements.”
- Summary: Article shows 3 different case studies showing varying methods of decoupling
- My takeaway: You need to make sure you understand your organizations requirements up front before you make architecture decisions that you won’t be able to easily change later.
Headless Drupal The Cake is a Lie (Gotta love the Portal reference)
- Notable Quote: “If you expect to be able to build your next project by simply configuring a few resources and putting together some React components or Angular directives you’re in for a disappointment. It’s going to take a little bit more than that. I’d say lot more”
- Summary: Article touches on many of the aspects related to setting up a headless website
- My Takeaway: Good breakdown of related issues when going to headless including loss of features taken for granted, performance considerations, and application dependencies.
What the Headless CMS Means for Marketers
- Notable Quote: “Be sure your decision to move to a Headless CMS is made only after working with a technology partner that understands both the business and technical cases for moving to a headless solution.”
- Summary: Article provides several good use cases on when it makes sense to move to headless.
- My Takeaway: Make sure you are choosing a headless system for the right reason and again, make sure you gather proper requirements and that they are communicated effectively to the development team or vendor who is building the site to make sure everything is very clear.
Headless Drupal and SEO: What Marketers Need to Know
- Notable Quote: “At this point, you might be wondering why everyone isn’t heading toward decoupled CMS. After all, as a marketer, being able to get content out to any device quickly is paramount. However, there is a price to be paid for this ability. In many cases, that price is quite high.”
- Summary: Article provides several real-world scenarios where functionality from a CMS (in this case Drupal) didn’t work as expected when shifting to headless. The article also provides several bullet points outlining issues that need to be considered to justify going headless.
- My Takeaway: Important considerations including a good example regarding meta tags. The Metatag module is developed to output the tags when Drupal renders the page but since that is no longer the case, custom code needed to be written to pull the meta tag data. This is just one example of how data won’t be rendered automatically when shifting to headless. Note that this will be the case with any CMS that renders its own pages.
Notable Quote(s): “The problem is that most of the WordPress ecosystem does not address API usage. For example, to enable custom-fields in WordPress requires a plugin and a self-managed WordPress instance. But once the plugin is setup and custom fields are created, there’s no documentation on how the custom fields would be fetched over an API In cases like this, the plugin-based extensibility of traditional providers like WordPress become useless and potentially impossible to work around.”
(regarding CMS selection) we recommend choosing your solution based on developer experience. Which CMS is the easiest to integrate? Which CMS has the best documentation? Which CMS has the simplest SDKs?”
Summary: Article provides several good considerations for choosing a headless CMS. They discuss using what they call “traditional providers†such as WordPress and Drupal versus others that are built solely around API integration. The article also covers related topics such as self-hosted versus managed hosting and pricing.
My Takeaway: This article illustrates the problems with trying to retrofit an existing CMS like WordPress that wasn’t designed for API first from the ground up in a similar way that the previous Drupal SEO article discussed the issue. However, there is a strong movement in the Drupal community to join the headless CMS revolution as evidenced by 2 new Drupal distributions. Contenta is a Drupal distribution built with a foundation based in API capabilities at its forefront for the existing Drupal community. Reservoir is another Drupal distribution created by Acquia (The pro arm of Drupal similar to Automattic for WordPress) which also aims to capture the headless CMS market in a more agnostic approach catering to developers that may not have any experience with Drupal. I’m not aware of any such distribution projects for WordPress so please leave one in the comments if you’re aware of any.
The article also illustrates how you shouldn’t ignore the existing knowledge and skill-set of your existing team when making the technology choices for your CMS selection. I also like how they focus a little on off-loading the dev-ops aspect with regards to self versus managed hosting which while not specific to this type of project is something I feel is another very important consideration.
2 Good Articles on the Pros and Cons of Headless
Ready Set Go
So you’ve made the decision to go headless or decoupled? Make sure you start with eyes wide open by reading The Hidden Costs of Decoupling