Back to Headless CMS
Headless CMS FAQs
About Headless CMS
Common questions about Headless CMS.
In the context of web and application development, the term “headless” refers to the process of decoupling the frontend from the backend.
Older, legacy applications traditionally approached the front and backend from a single source of code, with a CMS that powered both. A headless approach consumes data from various points via APIs, which provide raw data, which is then mapped into a frontend interface and displayed to an end user. This process allows for the development of much more intuitive frontend experiences, and for a backend that is more secure, scalable, and stable overall.
Older, legacy applications traditionally approached the front and backend from a single source of code, with a CMS that powered both. A headless approach consumes data from various points via APIs, which provide raw data, which is then mapped into a frontend interface and displayed to an end user. This process allows for the development of much more intuitive frontend experiences, and for a backend that is more secure, scalable, and stable overall.
Traditionally, a CMS would serve as a single point for delivery of both the frontend and administrative backend. With Headless CMS, the goal is to decouple these two major components of an application—allowing the technology for the backend and frontend to be better tailored to the needs of each.
Whether the move to headless is right for your business depends on unique needs that are specific to your applications and how they operate. Reimplementing monolithic applications can have a profoundly positive impact on any business. It’s important to speak to a Headless CMS development agency to determine the scope and breadth of how reimplementation of your current stack can best serve your business.
The web has seen significant shifts in recent years, in terms of how applications are developed and subsequent best practise. Part of these changes involve the use of decoupled backends, the implementation of microservices to power different parts of your applications, and a general shift to Javascript-powered web technology to aid in rapid development and increase code reusability and maintainability. At this point, it's clear that headless & composable architecture are here to stay, largely down to the level of flexibility businesses can achieve with this approach.
Technology
Technology, architecture & implementation questions.
At their core, the aim of a headless CMS is to provide a way to easily create and edit your content. This content/data needs to be hosted somewhere, as does the CMS itself. Headless content management systems are either self hosted (eg. Strapi, Headless Drupal), or are provided as a SaaS offering (i.e. Contentful, Sanity, Storyblok).
Whether a self-hosted or SaaS offering is right for your business depends on your needs in terms of scalability and control. Self-hosted options will generally provide an unrivalled level of flexibility and control, though require more hands-on maintenance by an in-house team or agency partner. SaaS CMS on the other hand, offerings provide a reliable, maintenance-free experience with minimum uptime SLAs and ready-to-use APIs supplied out-the-box, requiring minimal up-front configuration.
Whether a self-hosted or SaaS offering is right for your business depends on your needs in terms of scalability and control. Self-hosted options will generally provide an unrivalled level of flexibility and control, though require more hands-on maintenance by an in-house team or agency partner. SaaS CMS on the other hand, offerings provide a reliable, maintenance-free experience with minimum uptime SLAs and ready-to-use APIs supplied out-the-box, requiring minimal up-front configuration.
Replatforming
What's involved a migration and replatforming to a Headless CMS with us.
Migration to a Headless CMS is often part of any widespread digital transformation engagement. For websites and apps running on legacy platforms, migration to headless CMS often forms a vital part of enabling the backend to interoperate effectively with a new progressive frontend. We offer comprehensive migration services to orchestrate and execute the migration of large amounts of content from legacy CMS to headless CMS without infringing on the operations of content management and authoring teams. This is accomplished through the development of custom migration workflows which are responsible for migrating content either incrementally or at once, depending on the needs of your digital transformation project.
It depends. Oftentimes, The answer is yes—as most content management systems today support Headless implementation via built in APIs. Even for content management systems that don’t offer native APIs, usually plugins exist to make this possible, or alternatively this can be developed as a custom implementation. However, whether it’s the most desirable solution is a different matter. Content management systems that aren’t built API-first could potentially require large amounts of development work in order to achieve what is required to effectively implement them as part of a headless solution to building your application. Legacy content management systems that don’t natively support REST or Graphql APIs will require custom development of a potentially large number of bespoke endpoints to consume and send data back and forth from the CMS. Additionally, such content management systems may be largely incompatible with the progressive nature of Headless and composable architecture, and are likely to be clunky and resource intensive. Legacy CMSs have typically been built with programming languages that are less desirable in the era of the progressive web, require outdated server infrastructure, and feature largely bloated code bases which have been historically prone to insecurities.
In general, when considering reimplementing your CMS to support a new, API-first approach, it’s a good time to consider whether the cms still meets the changing needs of your application.
However, some traditional content management systems have undergone widespread innovations in recent years, making them more accessible in terms of APIs, and therefore sufficiently suited to incorporation within a headless stack. Wordpress, for example, can be effectively used as a headless cms, making it possible to retain a website’s existing backend while decoupling the frontend from the cms. Other traditional content management systems, such as Drupal, have undergone larger evolutions to become API-first with a full scope of support for implementing the cms as part of a headless build, which opens further possibilities for connecting existing CMSs to a decoupled frontend without upheaving the backend and current content.
It’s worth noting, however, that modern headless CMS are often built using more progressive web technologies and are therefore generally more amenable to integration with a decoupled frontend, as this is what they were designed to do.
In summary, it’s possible to enable support for headless implementation in your existing, traditional CMS (such as Wordpress or Drupal), but alternative options should be considered as there are newer, more progressive content management systems available, which are built specifically for omnichannel, headless experiences. The optimal choice in CMS will vary significantly depending on the website/application and it’s specific objectives.
In general, when considering reimplementing your CMS to support a new, API-first approach, it’s a good time to consider whether the cms still meets the changing needs of your application.
However, some traditional content management systems have undergone widespread innovations in recent years, making them more accessible in terms of APIs, and therefore sufficiently suited to incorporation within a headless stack. Wordpress, for example, can be effectively used as a headless cms, making it possible to retain a website’s existing backend while decoupling the frontend from the cms. Other traditional content management systems, such as Drupal, have undergone larger evolutions to become API-first with a full scope of support for implementing the cms as part of a headless build, which opens further possibilities for connecting existing CMSs to a decoupled frontend without upheaving the backend and current content.
It’s worth noting, however, that modern headless CMS are often built using more progressive web technologies and are therefore generally more amenable to integration with a decoupled frontend, as this is what they were designed to do.
In summary, it’s possible to enable support for headless implementation in your existing, traditional CMS (such as Wordpress or Drupal), but alternative options should be considered as there are newer, more progressive content management systems available, which are built specifically for omnichannel, headless experiences. The optimal choice in CMS will vary significantly depending on the website/application and it’s specific objectives.
Let's talk Headless.
We build modern digital experiences for disruptive brands.
Tell us about your project, and we'll get back to you with details on how we can make this happen.