What is a Headless Web Application, and When Should You Consider Using It?

When does it make sense to go headless?

Web development has drastically evolved in recent years. There are a series of options and possibilities to build websites and web applications. One thing I’ve learned in the 6 years I’ve worked in this industry is that each project and client has its own needs and particularities. We can not and should not apply the same approach and use the same technology stack.

For many years, developers have built websites and platforms on top of monolithic Content Management Systems like Drupal or WordPress. As more people used those technologies, their core, and plugins evolved to accommodate various needs, always enabling customizations. The idea of one system doing it all.

Using Drupal or WordPress can get as complex, and some projects don’t need the complexity of those technologies, either for reduced scope, budget, or timeline. Not every project needs the complexity and robustness that a full-fledged Content Management System (CMS) brings. We need alternatives.

With the rise of Static Site Generators and the JAMstack infrastructure concept, static sites were made dynamic with simple headless CMS, allowing editors to easily add and edit content without changing a line of code. We could build static sites with their speed and high performance while delivering a new website in less time and cost. As technology advanced, we could build more complex web platforms without relying on monolithic infrastructures, giving the front end more flexibility and possibilities for out-of-the-box designs.

In this scenario, we started seeing the rise of what experts call a Headless Web Web Application or a Decoupled Infrastructure — a web application where the front end is a different entity than the back end.

This approach brings a series of benefits to a web platform or website, but it is not something you should apply to every project. It is important to understand the needs and conditions of that specific project and determine if this is a good opportunity to separate the front and back ends.

Before we discuss the aspects and factors that influence decision-making, let’s first understand headless web development and its associated benefits.

In this very intuitive and simple article, Catherine Dee gives a very simple explanation of Headless Web Development:

“In the simplest terms, headless means “decoupling” the front end and back end, implementing a best-in-class API architecture. You’re separating where the content is stored — the content repository — from the presentation layer on which it’s displayed.”

Algolia

For instance, an infrastructure like this can make content endlessly reusable, eliminating manual processes like copy and pasting and making editing way easier — change the copy or image in one place, and the change applies everywhere the content is located. As put in this Storyblok article:

“A headless CMS is a backend-only content management system that’s built from the ground up as a content repository. The content is then accessible via a RESTful API or GraphQL API for display on any device. This separates your data (the “body”) from how it’s presented (the “head”), hence the term “headless”

Storyblok

In recent years, this approach has also been considered part of Composable architecture:

Composable architecture is a modular approach to software design and development that builds flexible, reusable and adaptable software architecture. It entails breaking down extensive, monolithic platforms into small, specialized, reusable and independent components. This architectural pattern comprises a pluggable array of modular components, such as microservices, packaged business capability (PBC), headless architecture and API-first development that can be seamlessly replaced, assembled and configured to align with business requirements.

The New Stack

It allows the use of API infrastructure to expose data and functionality to a web application, leveraging third-party services and integrating everything on the front end.

Separating the head from the body (data) can be beneficial in some projects. Suppose you have an eCommerce store that needs to be updated across different websites and marketplaces. You don't need to replicate this change manually if you have one source coming from a single Content Warehouse.

The same could happen if you have different sources of data to be presented on the same website. You do not always need to put everything under the same infrastructure, and the data must come from different sources and be served to the front end.

For instance, we have recently built a Live-Streaming platform where the recordings and live videos come from one place, and the copy with information from each session came from a Content Management System. Instead of putting everything within a CMS and serving it in the front end, we built an architecture where the videos are served directly to the front end.

Another important thing to remember is that a project doesn’t need to be monolithic or headless. A web application with some headless or decoupled parts can be monolithic at its core. Let’s say you have a media website with information about your company and a series of news articles and events that must be distributed to other platforms and websites. While most of your content comes from your CMS, the events come from a different database and are served directly to the front end without passing through the CMS.

Pros and Cons

In a nutshell, the pros of Headless web development are:

• Better scalability and performance for websites with peak traffic
• Multi-channel delivery
• More flexibility for designs
• faster frontend delivery
• Leverage third-party services

However, not everything about this approach is beneficial. Some of the constraints of Headless CMS can be:

• Additional overhead with API development and management
• It can get very complex depending on what you’re building
• Potential higher costs of development
• Fewer layout options and flexibility for editors.

When should we consider using Headless?

This is what we usually try to cover when we ask ourselves this question:

• Must have the same information across multiple channels and devices, such as website, App, sub-sites, e-mail, etc.
• Provide personalised user interfaces and out-of-the-box experiences.
• Performance will impact the web application’s service.
• Peak traffic websites and applications that need to be easily scalable.
• Website that does not need to have many layout options for editors
• Real-time Notifications and Information delivered across different channels.
• Reduced Budget or/and reduced timeline.
• Must rely on third-party service providers for specific parts of the website.

From my experience, the following client profiles or projects can benefit from a headless approach:

• Small and medium Marketing websites → don’t need all the complexity that Drupal or WordPress offers.
• eCommerce and catalogues → require seamless integrations with various channels, such as websites, mobile apps, and marketplaces.
• Media and publishing → large volumes of content must be distributed across multiple platforms.
• Multi-brand Corporations → Large corporations with multiple brands or subsidiaries can benefit from a headless approach to ensure brand consistency while maintaining individual brand identities.
• Governmental Institutions -> distribute the same information across multiple platforms and channels while providing real-time updates.