We work with many different content management systems for various clients. They all cover the basics, and each provides a set of unique features that clients value over those provided by the others. One of the major features a web content management system provides is the ability to manage content. This includes the ability to authenticate users, a rich content editing experience, media management, and more. So starting a new website on a CMS platform gives you a jump start, and saves money.
But if you're a developer there are unavoidable compromises. One of the biggest is that even if you love the back office features, you may not like the way it handles publishing. WordPress provides a good example. The back office tools are really mature, and so long as you manage the number and quality of plugins, it's pretty easy to navigate. But creating a responsive theme for WordPress can be tricky. You need to learn the WordPress theme architecture, the API (which is based on PHP), and maintain your changes to the theme across WordPress updates, among other considerations. You have to go "all in". But if you do there are some drawbacks, including:
- following a CMS-specific publishing architecture,
- learning a CMS-specific API,
- learning to build CMS-specific plugins,
- sticking to a CMS-specific development language,
- accepting the risk of being left behind as new design patterns and web application paradigms evolve (like single page apps),
- and maintaining compatibility across CMS platform updates.
Each CMS has its own way of doing things, mitigating some of the problems I've listed. For example, one of our favorite content management systems, Umbraco, has a pretty open ASP.NET MVC environment, allowing seasoned .NET developers an easy way to create templates. But it still requires ASP.NET and using their custom objects and methods to render content.
Off With Their Heads!
One of the ways a developer can address the limitations of adopting a CMS platform is to only use them for the purpose in which they excel: managing content. A developer can accomplish this with a headless CMS strategy. No guillotine required.
LET THEM SERVE CONTENT!
— Marie Antoinette (OK, not really)
The key to this strategy is being able to communicate with the CMS using a REST API, allowing a developer to create the front end of the site using any technology stack they choose.
REST stands for Representational State Transfer. It's a methodology designed to let websites, software, and services talk to each other in as simple a way as possible.
It's an inherently flexible format but implementations are expected to share certain core characteristics. Here are four key expectations:
- Use HTTP methods explicitly: It takes place over the web with standard HTTP methods such as PUT, GET, POST and DELETE.
- Be stateless: The client will include any state information needed in the request to the server and vice versa.
- Expose directory structure-like URIs: Use familiar URL structures like http(s)://api.com/students/jane
Another benefit of a headless solution is that you'll be able to provide managed site content and other data to dedicated mobile, tablet, and desktop applications.
Knowing all this, how would a headless strategy specifically address the limitations I mentioned previously? Let's take a look.
...following a CMS-specific publishing architecture
In a headless CMS implementation, the front-end is decoupled from the back office tools, allowing a developer to write it with whatever stack or pattern they choose.
...learning a CMS-specific API
This is a bit more of a dubious improvement, as a custom object and method API is replaced with a REST API. But generally speaking, a REST API is easier to use and is available outside the CMS environment, which is a huge benefit.
...learning to build CMS-specific plugins
Building the website with your own stack and pattern allows you to author components as you see fit, using most any technology you choose.
...sticking to a CMS-specific development language
Since the developer is building the website with most any technology they like the scripting language is part of that decision.
...accepting the risk of being left behind as new design patterns and web application paradigms evolve (like single page apps)
Since the developer is building the website with their own technology stack and development pattern, they can look ahead and future proof as needed. But even when they have to rewrite the website using completely different technologies, they can.
...and maintaining compatibility across CMS platform updates
The great thing about a REST API is that it's generally pretty static, other than additions. So as new REST API features are added, a developer simply leverages them in the website as-needed. The existing stuff keeps on humming along.
If you have a website, intranet, or product that could benefit from a new architecture, we'd love to hear from you! Maybe a headless CMS is just what you need.