Since their introduction, content management systems (CMS) have made life easier for website developers, site owners, and administrators alike. Platforms like WordPress, Joomla, and Drupal account for more than 60% of all web content platforms. The only problem is their relative lack of flexibility. This is mainly due to the fact that the front and back end functionalities are deeply coupled.
Table of Contents
- Anatomy of a CMS
- Cutting Through the Clutter
- Decoupled CMS
- Decoupled vs Headless Systems
- Losing Your Head: Pros and Cons
- Tech Agnostic
- Better performance
- Licensing fees
- Content-as-a-Service (CaaS)
- No default WYSIWYG editor
- Fragmented Tech Stack
- Picking a headless CMS
- Popular Headless CMSs
- WordPress REST API
- Go Forth, Go Headless
With the rise in popularity of decoupled architectures like the JAMstack, CMS's have been increasingly shunning traditional database-driven systems in favor of API driven ones, known as the "Headless CMS".
The traditional CMS is a monolithic structure which provides out of the box solutions for templating and styling that are customizable via a WYSIWYG. As a result, designers and website builders can create professional-looking sites without needing to write a single line of code.
Since you’re encouraged to use the templates and style sheets that accompany a particular CMS, your ability to easily update or migrate content is limited.
As opposed to a traditional CMS, headless CMSes intentionally “chop off the head” thereby decoupling the front end from the back end. It therefore has no default frontend system and completely relinquishes the decision of presenting content to the developer.
As a result, it provides developers with greater flexibility in deciding their own architecture while letting them harness the strength of a CMS as a database. Moreover, because of the framework agnostic architecture of a headless CMS, you don’t have to worry about platform compatibility or database connectivity errors, as is common with WordPress.
In order to really grasp the elegance of headless CMS - and its possibilities - you have to cut through the clutter and understand how they work fundamentally. To start, let’s define a few terms:
Application programming interface (API) - a communication system that sends information to the server and back via user requests. How the API calls are answered depends on the specifications of the front-end protocol. When a content management platform is called API-driven or API-first, that means it's a headless or decoupled CMS.
Headless CMS - a content management system that contains only the back-end developer environment, with no default templating system or frameworks. These are a subset of decoupled CMSs.
Hybrid CMS - this is another name for a decoupled CMS. Such systems offer many of the benefits of fully headless content management systems, but come with optional tools and frameworks in the box to make the developer's work more efficient.
Front-end agnostic - when a CMS doesn't contain a default front-end design platform, it's said to be front-end agnostic. This means it can work with a variety of front-end frameworks.
In the above section on terminology, I mentioned the idea of a Hybrid CMS or a decoupled CMS. A hybrid CMS is not unlike a headless CMS except for the fact that it offers front end delivery tools like templates or default styles for instance. You can think of this like chopping the head off and making it available as a blueprint of sorts so you aren’t completely on your own when it comes to connecting the head and the tail.
Now that we've teased apart the differences between a headless CMS and a hybrid/decoupled CMS, a common next question would be "which system is better"? Generally speaking, if you want to publish on multiple channels, and you're comfortable with a bare-bones, API-driven system that has limited tooling choose a headless CMS.
But if you’re looking for a happy medium because you prefer the extra help, choose a hybrid or decoupled platform.
You may be under the impression that decoupling from your CMS is the only benefit of using a headless CMS. However, there's more than just developer freedom on the line.
Additional advantages of going headless include:
As long as the API endpoint is available, you can continue to communicate with it without too much of a maintenance burden.
You're not confined to design, style, or generic templates.
Since there's no front-end, your server will use fewer resources managing layouts and templates for dynamic websites.
Headless content management systems often don't require a copy of the CMS engine before deployment. That means the possibility of saving on licensing fees, from using the CMS or any other software.
Another name for a CMS, this is a subcategory of Software-as-a-Service. These are usually offered by a managed cloud “CaaS” providers like eZ Hosting, Surfcode and Contentful, and sold as a monthly “SaaS” subscriptions, which enables content delivery on demand.
CMS-es often come bundled with third party plugins that can introduce security vulnerabilities to your application.
While there are many benefits to using a headless CMS, they are not without disadvantages.
No default WYSIWYG editor
Headless CMSes don't come with a default editor, and often require content in the form of markdown. This can make the content creation process frustrating to those who may be used to WYSIWYG editors like wordpress.
Fragmented Tech Stack
Headless CMS-es require devising your own stack. While this gives developers the full flexibility of building a stack, picking a stack introduces a huge cognitive load at the start of a project.
In today’s market, you’re spoilt for choice when it comes to picking a headless CMS…..
*Security and access *- How will these be managed, and by whom? Common CMS platforms like Drupal and WordPress are notorious for having security vulnerabilities, which necessitates regular updates of the CMS software. Conversely, a headless CMS has no database to be attacked; your primary concern as an admin should be protecting sensitive content, and providing access to the appropriate parties.
Content previews - How will previews be handled? Because headless CMS systems are newer, many don't include the ability to preview content before going live. If previews are essential to your content strategy, make sure to use a headless CMS that offers them as a feature.
How will you sync UI/UX across multiple platforms and devices? When choosing a headless CMS, it pays to do a bit of testing first. Check to see how your content displays on any and every device. You’ll want to maintain the same UI/UX (re: look and style) across all screens.
Cache management - Unlike coupled CMS platforms, considerations like when to return to the data repository, when and how to clear the cache, and when a cached version of a CMS needs to be served are considerations that the front-end developer needs to establish.
Data migration - Are there options for migrating data from one CMS to another or tailoring it to different devices and operating systems? Many businesses today use “managed” WordPress hosting, for example. Though convenient (and open source), moving content out of WordPress can be clunky. Headless frameworks like Hugo have tools to help with the migration process.
Here is a list of popular headless CMS that you can explore and see if they could fit your projects.
Netlify is a great site and we even use it here at Scotch for our dashboard.
WordPress REST API
WordPress has adapted well with the times. You can now use WordPress dashboard as your headless CMS and they provide a REST API that you can consume with any frontend technology!
Today, we no longer engage with content on a single device or channel when surfing the web. It’s common to use desktop computers, smartphones, tablets, and any number of internet-connected IoT devices. If you want your content to remain fresh, dynamic, and available on any platform, consider using a headless or hybrid CMS.
Like this article? Follow @_danfries on Twitter