Written by Conrado Depoian— Product Manager at AMARO
What is a headless architecture?
Before we start talking about headless CMS (Content Management System) it is important to clarify what the term headless stands for in the context of software architecture. The concept of headless is rather new and is also often denoted as decoupled architecture. This term is mainly used to describe a type of architecture in which the code/service base, responsible for all the business logic and data structure and management, is explicitly separated from the client side, which renders a different set of contents by invoking both logic and data from the base.
Why going headless?
By leaving the responsibility for user experience completely under control of web and mobile application, we can exploit several advantages of headless::
- Setting front-end applications free — Front-end developers are free from any back-end mandatory structure and also have full control over the tools they will use to deliver user experience, providing more flexibility to innovate.
- Performance improvement — An application that is now responsible only for delivering content and no longer needs to make decisions based on complex rules like in a full-stack application can provide faster responses.
- Truly mobile — Simplifies connection with mobile apps since all functionalities are available in a service format through APIs.
- Omnichannel experience support — Through centralizing the business logic and data structure on the back-end it becomes much easier to provide complete user experience through any channel.
- Future readiness — The site design can be refreshed without the need for re-implementing the whole thing.
- Faster platform updates/transition — By having responsibilities clearly split among the correct systems and strictly requiring a service based approach, the system legacy is much lower than in a full-stack application, which speeds up any platform upgrade or transition that might be required in the future.
Clearly, headless approach is not a silver bullet and has some disadvantages. Among the main ones are complexity to set a good SEO (Search Engine Optimization) strategy, along with having to set a more senior team, since managing multiple systems can be challenging and the team’s expertise must cover them all.
What is a headless CMS?
In terms of applying headless architecture, a decoupled/headless CMS is necessary since a part of content provided to site users does not come from the back-end application. The management of this content is made through a headless CMS that also delivers editorial content and administrative tools on a service based structure through APIs.
Historically, the concept of headless CMS was set as a way to overcome the need for a more mobile world, where the CMS presentation layer was no longer important and where content is service-based extracted from a CMS into applications.
Matching with Digital Business Needs
A headless CMS, when comparing to traditional ones, contains just the content management component and no longer the presentation component. This concept is completely focused on the administrative job of the creative team. Splitting those responsibilities not only allows business teams to be more organized, but also strongly depends on that organization.
A digital and multi-platform world demands a unique and centralized location for content administration in such a way that the ability to fit such content into any application/device/browser is no longer under the CMS responsibility. On the other hand, a pure headless CMS should be 100% API based, so then it would deliver all its structured content to any client system.
In this way, business areas can be fully focused on the core of their knowledge and responsibility, which is engaging customers through their journeys.
Product View
As a Product Manager at AMARO, I should mention the value a pure headless CMS can bring to our product.
Besides the ones I’ve already mentioned above, such as provision for site design that can be refreshed without a complete refactoring cycle, and the significantly lower system legacy generation than in a full-stack application, which speeds up any platform upgrade or transition that may be required, I can list some others:
- Improves Business Time to Market ⇒ The independency of other systems/services helps product teams to apply the agile concept of bringing value quickly rather than waiting for a whole monolit implementation/deployment.
- Operational Improvements ⇒ Both infrastructure and daily activities become simpler. A Headless CMS usually offers SaaS approach built on top of cloud architectures, which reduces infrastructure costs. It also provides much less complexity since users become focused on content management only.
- Flexibility ⇒ By promoting a microservice architecture, being completely decoupled from front and back end applications, code reusability composability and maintainability get improved, which in turn provides freedom to choose technology and lowers the impact to other services.
- Scalability ⇒ By being properly decoupled, the CMS provides independent scalability, which is great since it does not impact other systems/services.
In conclusion, I’d like to share one of the best advantages of headless CMS application that can also cause some pain: It is possible to build everything in a headless CMS but it is necessary to build every single thing in it. With a headless CMS, the autonomy level of the one who’s operating it is lower than with an open system like Squarespace. Every custom layout will require code development, which is good in the sense of making sure very important concepts like mobile first, responsiveness and performance will be considered, but can also bring as sense of dependency on the engineering team.
