Table of contents
All these discussions around headless CMS and traditional CMS might have left you weary and disoriented, which is why our article today will try to take things on a different route by focusing more on helping you thoroughly understand the matter—and avoiding all the unnecessary talks in the process.
Understanding the traditional CMS
The definition
The traditional, coupled CMS is your typical content management platform with everything—the frontend (the presentation layer) and the backend (the content database and the editorial interface)—tightly and directly connected together, allowing for an easier time of managing content.
What traditional CMS means for practical use
Having everything directly linked in a systemic level like this means that you can make changes on your backend and have them reflected on your frontend with minimal configuration. In this way, even the non-technical members of your team will find it an easier time to manage and publish content on your website.
The practicality of traditional CMS is best seen in a blogging platform like WordPress. In WordPress, the process of managing content is made to be user-friendly, with changes to fonts or layouts of a website done via the click of a button on the dashboard. Installing of additional functionalities in WordPress is also a breeze, as you can always download and install plugins directly from the backend.
| Examples of Traditional CMS |
| WordPress, Squarespace, Magento |
How traditional CMS dictates a system’s capabilities
In a broader sense, the traditional CMS is conservative and with limited scalability.
Conservative: From the perspective of a developer, it’s hard to innovate in a traditional CMS since the system itself is rigid and monolithic in its nature. And since the frontend and the backend of a traditional CMS are tightly linked together, any new functionality that is implemented onto the frontend also needs dedicated backend support of its own. This is the reason why you should see system-wide maintenance being a regular thing with traditional CMS, as these maintenance are required to roll out new functionalities and ensure stability across the entire system.
Limited scalability: If you add layers and layers of new functionalities on top of your existing ones in the traditional CMS, chances are you will run into performance issues since not all of these new functionalities are built for your specific system. Coupled with the fact that implementing new functionalities are oftentimes a nerve-wracking process with traditional CMS, scalability remains to be an inherent drawback of traditional CMS that is unlikely to change anytime soon.
| Limitations | Descriptions |
| Conservative | Traditional CMS discourages innovating and experimenting due to the way the frontend and backend are tightly linked together. |
| Limited scalability | Scaling upwards in traditional CMS is hard due to the lack of choices available (i.e., being tied to a specific platform). |
The case for headless CMS
There’s no coincidence how Amazon got to its current place. Given the fact that Amazon pushes out a new frontend every few seconds with their completely decoupled CMS—and that AWS (Amazon Web Services) takes up over 70% of their operating profits—we’re led to believe that Amazon is not so much an eCommerce company, as it is more of a technology company with an eCommerce business on the side. And this makes sense since it’s only with a decoupled, headless CMS that Amazon could achieve a level of flexibility and scalability that are unattainable otherwise with the traditional CMS.
Headless CMS: The definition
“Headless” is more about the way the backend of the headless architecture functions—by paying no attention to the head (the frontend). But since every system needs a head—as even the most bare-bone system still has a terminal to display all the necessary information—going headless doesn’t seem to be all that practical to the average layman. Because why lose the head?
This is when the headless architecture can be redefined in a simpler way—a (multi-headed) content management system in which content is delivered to the head(s) (presentation layers) through the use of APIs. In this way, a piece of content, for example, is publishable to multiple frontends and to multiple platforms at once. Consequently, this means that development in headless CMS is asynchronous in its nature, with frontend changes being able to be made without fear of affecting the backend, and vice versa.
| Examples of Headless CMS |
| Contentful, Kentico, Magento Commerce |
Understanding the APIs in headless architecture
API can be regarded as the core component of a headless architecture. It is, in simple terms, a way for different systems (with different programming languages) to communicate with each other.
Through APIs, a Product List page on your frontend can request for data from your backend without really knowing how your backend works. What this means in practice is that, as long as the APIs in use are fully compatible with your system, your business isn’t constrained to one single backend and/or one single frontend anymore, and they can be replaced without crippling your whole operation. Moreover, since you’re not limited to just one frontend, a piece of content can, consequently, be made available to popular or even unconventional frontends, such as vending machines, billboards, wearables, and much more.
Knowing when to choose headless CMS
The pros and cons of headless CMS
As almost everything in headless CMS revolves around APIs, the architecture itself is more practical and technical than your traditional CMS. And this means editing and publishing content in a headless CMS won’t be as hand-holding of a process as compared to the traditional, monolithic architecture; but in return, you get much more freedom to create whatever type of content you want and not be restricted to the platform in use.
In a pure headless CMS platform like Contentful, for example, you can create content models that serve as blueprints for your content. These content models open up more ways for your content team to create content and act as the key for a diverse and flexible CMS.
Source: Contentful
Despite the fact that the architecture itself is made for scalability, maintenancing a headless CMS is not as easy a job as compared to the traditional CMS. It all boils down to the fact that in headless CMS, you and your team are fully responsible for all the maintenance and upkeep jobs (including the maintaining of your custom APIs). This total freedom to develop and innovate also means that you only have yourself to fall back on, and that developing and maintaining a headless CMS can be costlier than you expected since there is a higher level of technicality and risk involved in the process.
If your team is inexperienced in dealing with headless CMS and all the abstraction that goes with it, chances are it might even delay your business’s time-to-market.
The headless architecture itself is a choice to not be tied down to a single platform and everything that comes with it. For a typical eCommerce operation, for example, you can choose a flexible headless solution such as Headless Magento with its complete APIs to power your backend; and then—knowing that you’re not limited in choices—you can opt for another third party ERP to manage your finances and logistics.
| Pros | Cons |
| Modular backend(s) and frontend(s) | Costly to develop |
| Allows for asynchronous development between the frontend and the backend | Requires coding knowledge |
| Content can be made available to even unconventional devices such as billboards and wearables | Might actually delay time-to-market due to its high level of difficulty in implementation |
When to choose headless CMS
It used to be that headless CMS was bleeding-edge and inaccessible to smaller-sized businesses, due to the amount of work and cost involved to properly implement a functional headless system. With time, however, headless CMS is now made mainstream and accessible to everyone.
Since there are still several drawbacks that are associated with headless CMS, businesses that want to go headless should only consider this approach when they think their businesses have the potential to scale upwards, and have the resources that are required to both develop and maintain a headless CMS.
In fact, you could even be finding yourself missing most of the functionalities that you take for granted if you opt for the headless approach, as there’s no out-of-the-box multilingual experience with headless CMS. Even a site search function on your website, for example, can be challenging to implement as it could take several weeks or more for the feature to be completely stable.
Does traditional CMS still have a place?
When you weigh in all the pros and cons of both CMSs, a traditional CMS would make more sense for businesses that want only a CMS to conveniently and easily manage content for their web-delivered website. For cases like this, going headless would mean going the extra mile for relatively little gain—it is overkill, and will hurt your time-to-market.
Lose your head
With platform vendors embracing headless CMS at a rapid pace, continuously rearchitecting their systems to enable internal API calls that can be used with third-party or custom-developed external frontends, deploying a headless system now is a much easier process as compared to years ago.
Magento is one prime example of how headless CMS is only becoming more mainstream as we go forward. With its complete APIs to start with, developers can build their own headless commerce and enjoy all the benefits of a flexible content managing system. Coupled with a Progressive Web App as the frontend solution, merchants are reporting increased conversion rates across the board, as well as boosts in other important metrics.
For Magento merchants wanting to go headless but have yet to find a reliable solution provider to make the jump, here at SimiCart we offer the full solution, ready to transform your in-store shopping experience.
