Content Management Systems… people like to use them. And not just a few people, apparently almost half of all sites use them! Furthermore, alongside the traditional CMS, a new concept called Headless CMS has emerged as well. It’s become quite the buzzword in the web development community, to say the least. Yet then again, since it’s so new, here you are googling “Headless CMS Explained – What, Why and When”… I hope 😅. So let me do some explaining, alright?
When talking about a headless CMS, we mean that the frontend (i.e. the head) has been cut off from the backend (i.e. the body). In other words, a CMS like WordPress wouldn’t be in control of the visual layer of the site anymore. Instead, it would feed its content to the frontend via a RESTful API. Seems pretty simple, right? But wait, there’s more! 😛
Headless vs Decoupled
Next to the term headless, the word decoupled gets thrown around a lot as well. And more often than not they are used interchangeably, even though they shouldn’t be! 🙅♀️ While both are incredibly similar and deal with an independent front- and backend, a headless CMS is actually a subset of a decoupled one! So what exactly is the difference?
With a decoupled CMS architecture, the way the data is consumed and presented on the frontend is already predetermined. For instance, you may have a CMS that may only work with ReactJS on the frontend. On the other hand, with a headless CMS architecture, the frontend is not predefined in any shape or form. Rather, the CMS just sits there 🦥 with its API ready to be called by anything. This means the provided data could be consumed by anything, ranging from a website and an app to even an Internet of Things (IoT) device.
Now that you understand what a headless CMS is, the next topic at hand is why you should use it. And let me tell ya, there are a few reasons why you should! 😁
With a headless CMS, you’re no longer restricted by the CMS’ templating framework. Rather, you’re fully in control of how the content is displayed, providing a better user experience. 😊 In fact, you may choose to build the frontend in whatever technology stack you find suitable, which more often than not translates into a more modern workflow for developers.
Along with this, you forgo the need to update your frontend application to keep it compatible with future versions of the CMS. Even better, you’re getting rid of a lot of bloat from the CMS and are only implementing necessary functionalities.
Remember what I wrote earlier? 📝 Data provided by a headless CMS can be consumed by anything. How does this represent a strength? Well, content no longer needs to be rewritten for each communication channel. Instead, it may be centrally stored and managed by the CMS and simultaneously diffused to multiple channels.
What happens if the CMS goes down? 👎 Heeeelp! Well, actually nothing happens… Frontend applications are not affected in case a CMS goes offline since they’re decoupled. Even better, this is also means that there won’t be any downtime in case of maintenance.
Given that your frontend is decoupled from the backend, the former lacks a database through which hackers could gain access. In turn, this significantly lowers the risk of DDoS attacks. Furthermore, sensitive content provided through the CMS’ API service can be secured by using authentication services and a secure protocol.
Lack of Visualization
Unfortunately, nothing is perfect. As such, a headless CMS does suffer from a peculiar weakness. Which one you may ask (if you haven’t read the heading…)? 🤔
The poignant disadvantage you’ll encounter as a content creator of a headless CMS is the lack of visualization or preview. Without this feature, it becomes difficult for them to know what the content will look like for end users. This may lead to frustration and at times a loss of productivity.
Alright, now we know the what and why. It’s now time for the when! 😎 Soooo, when should you actually use a headless CMS, or rather when should you not?
CMS’ such as WordPress are known to be overly user-friendly. Unfortunately, this has brought about a ton of not so great looking and/or well-built websites. Conversely, a headless CMS is more on the other extreme. You better have a team of developers 👨💻 to create that frontend layer of your application.
Yet, this can pose a bit of a problem for smaller companies that lack the necessary budget to do so. In such a case, it might be recommended to opt for a traditional CMS.
Or even worse, 😥 it may be difficult for the company in question to make the transition to a headless CMS due to the development team being entrenched in legacy CMS technologies.
If your company wishes to employ an omnichannel strategy to diffuse content across multiple platforms, then a headless CMS may be the choice for you! 👈 Yet again, if your company lacks the necessary scale in terms of channels and budget to support such a strategy, it may be better to stick to a traditional one.
Did you find what you came for? Want me to cover something else? Let me know in the comments below! Share, if you liked this post!