Deliver superior customer experiences with an AI-driven platform for creating and deploying cognitive chatbots
Deliver Awesome UI with the most complete toolboxes for .NET, Web and Mobile development
Automate UI, load and performance testing for web, desktop and mobile
A complete cloud platform for an app or your entire digital business
Detect and predict anomalies by automating machine learning to achieve higher asset uptime and maximized yield
Automate decision processes with a no-code business rules engine
Optimize data integration with high-performance connectivity
Connect to any cloud or on-premises data source using a standard interface
Build engaging multi-channel web and digital experiences with intuitive web content management
Personalize and optimize the customer experience across digital touchpoints
Build, protect and deploy apps across any platform and mobile device
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 Developer Advocate focused on Sitefinity. He is passionate about web development and sports. Prior joining the DevRel team, Pepi was one of the team leaders in the Telerik Web Components division.
Copyright © 2018 Progress Software Corporation and/or its subsidiaries or affiliates.
All Rights Reserved.
Progress, Telerik, 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.