If you do much web development these days, chances are you’ve heard the term “headless CMS” or “decoupled CMS.” “Headless” and “decoupled” CMS (content management systems) are a little bit different from each other, but for the purposes of this article, I will be talking about the headless CMS.
What is a headless CMS?
A headless CMS is a lot like a regular CMS in that it provides a way to store data and handle CRUD (Create, Read, Update, Delete) actions. Where they differ is that a conventional CMS provides a way to display the data whereas a headless CMS does not. The headless CMS will instead provide an API (application programming interface) that can be used to retrieve the data from the CMS.
So when we’re talking about a headless CMS, we’re talking about a setup that has:
- Some kind of database-driven CMS that handles all of the CRUD actions and only manages content. It has no way to display any of the content it holds.
- The data needs to be accessible by some kind of API, preferably returning JSON.
- A front-end that can be built in any technology that can consume the JSON and render the HTML.
That sounds pretty cool, right? It is. It’s really cool. You can create your content one time and make it accessible through any number of channels and platforms. In a sense, future-proofing against new channels or platforms.
That’s what draws developers to the headless CMS. Brands don’t want to have redundant data in order to serve different channels. With a headless CMS the data is there and can be consumed by any number of platforms, for instance native mobile apps. The CMS can be built one time and the content is stored in one place while still accessible from just about any platform.
Front-end developers are excited by the idea that they can use whatever front-end technology they want to consume the CMS data as they aren’t tied down to any certain technology or templating languages. Decoupling the CMS from the front-end also helps to lower the cost of a redesign in the future. You could even use multiple front-ends to consume the data from the headless CMS, if you were so inclined.
We were recently working on a big project that we really wanted to stretch our legs on, and do some cool stuff. We usually use WordPress as a CMS, but before this we’d never tried to implement WordPress as a headless CMS. We figured this was the perfect opportunity to give it a shot. We knew what data was going to be housed and how we were going to house it, but we really didn’t know visually where we were going yet. We also knew we may be needing to consume the CMS data from any number of different channels in the future, and we wanted to make sure that could be done without needing to have a separate data source.
For me to explain exactly how we accomplished this is outside the scope of this article (maybe another subject in the near future), but we did accomplish it. We used WordPress as the CMS and wrote a completely custom front-end using Node and Vue, that consumes the data through the WordPress Rest API. So far it’s really worked well and we haven’t come across any issues with the setup since we launched. The site is super fast and we were able to present the CMS data in some really cool ways.
Should you use headless CMS for your website?
Is a headless CMS right for your project? Who knows. It just depends on your needs and the project requirements. But, if it sounds like a headless CMS could be a solution you should definitely give it a try. If nothing else it will be a fun exercise.