In recent days I’ve spent some time reading more about “headless” and how this will conquer the world and if I don’t use it my business will fail :D. With this post I want to share what the real risks and solutions are. I will iterate through the different concepts that are currently receiving a lot of hype. Many of those terms are blended and some people are using them interchangeably, which is why I will explain each of them separately.
With the increased usage of devices beyond computers, businesses want to have a presence and display content everywhere, you name it – smartphones, watches, kiosks and even refrigerators. According to some “specialists” the best approach is to use a Headless CMS that is designed to store content and retrieve it through APIs, with no frontend attached to it. This way every frontend application could consume the data regardless of the technology stack, so your content becomes platform agnostic and the whole system is decoupled. The CMS becomes a centralized place where you store your content.
An issue comes when you use a CMS without a robust API. It limits the channels that you are able push content to. Now organizations have no way to push content to other apps, such as native mobile apps, because the content is specifically designed only for browsers. Said a different way, you need your content to be in pure text or at least in a standard format.
What if the standard CMS follows the best practices (I believe that everyone should, if they don’t, please don’t use it in the first place :D), and it has decoupled architecture and that exposes APIs and cleanly manages the content? It seems that you will be able to publish content everywhere.
The conflict with many of “headless advocates“ and the press is that your CMS will have a “head” because you have a dedicated frontend. However, with the API-first approach you can tackle the problem with multiple device content delivery no matter what. Keeping your “head” does not obligate you to build the frontend with the built-in functionalities, you can still use a framework of your choice – Angular, React etc.
Having the concept of the “headless CMS” immediately brings another level of abstraction that could be built on top of it, which is “headless CMS” delivered via SaaS. This model is heavily promoted as superior to a standard CMS, but content as a service is really just a CMS hosted in the cloud and used to store content. Unfortunately, I couldn’t find any compelling arguments why this approach is better, since the cloud deployment is relatively easy and it is done by only clicking a button (e.g. Azure). Keep in mind that developers love to have control of everything, especially when we speak about APIs and deployment.
The other challenge is when your frontend is created with a different technology and it is not deployed out of the box with your CMS. Usually the CMS has built-in personalization and customer journey tracking, but using 3rd party frameworks you need to implement these things yourself. The headless advocates are often met with resistance by marketers as they feel the headless model limits their ability to leverage tactics like personalization and customer journey optimization across all apps. However, leveraging a technology that easily integrated 3rd party data and applications enables marketers to quickly leverage any tactic they desire, regardless of the app.
There are many headless CMS systems on the market and they have their success stories, but I wouldn’t say that we should abandon the standard CMS solutions, especially those that have good architectures and decoupled APIs. They are better in many ways but you may never have thought about them as headless 😊 especially when they are not advertised as such.
All of the hype is centered around two problems – coupled architecture and inability to deploy in the cloud. Those two problems were solved many years ago by every top CMS on the market and no matter what the fuss is all about, the root of everything is simple calls to APIs and quick deployment in the cloud. If you don’t believe me ask your developers 😉.
If you are interested in how Sitefinity could be used as a “headless” CMS with a brain, please read the following article.
Peter Filipov (Pepi) is a Product Manager focused on expanding Sitefinity ecosystem. His prior experience as a Developer Advocate and Manager of Engineering helps him to understand the customers’ and market needs of Sitefinity. He also is passionate about being active and healthy 24/7 😊.
Subscribe to get all the news, info and tutorials you need to build better business apps and sites
You have the right to request deletion of your Personal Information at any time.
You can also ask us not to pass your Personal Information to third parties here: Do Not Sell My Info
Let our experts teach you how to use Sitefinity's best-in-class features to deliver compelling digital experiences.
Copyright © 2021 Progress Software Corporation and/or its subsidiaries or affiliates.All Rights Reserved.
Progress, Telerik, Ipswitch, Chef and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks for appropriate markings.