Headless architecture helped us gain full flexibility and efficiency

You might have heard it by now, everyone is talking about headless. Headless CMS, headless commerce, headless beer (ok, maybe not the last one). There are already great resources and articles that discuss headless architecture at every level of detail. So, do we really need another one? We say yes!

In the following, we discuss the pros and cons of headless architecture. You will learn when it makes sense to adopt headless architecture, and when you should think twice. Finally, we wrap up with our approach on headless architecture for e-commerce and CMS projects.

Let’s start with the basics

The term headless is often used in combination with content management systems (CMS) or e-commerce, areas that have been dominated by large monolithic applications. What’s a monolith? A monolith combines the user interface and data processing layer — e.g. business logic that reads data from the database — in a single application. Think of WordPress and Magento. Both come with a plethora of functionality to cover as many use cases as possible. And lots of functionality is nice, right? Well, it depends. Chances are that you might only need a fraction of what the system provides. Yet within the monolith, the functionality you really need might be tightly coupled, making the system restrictive and difficult to extend.

Monolithic applications vs. headless systems

This is where headless really shines, as it is a subset of the microservice architecture: small, independent services, dedicated to a single task that communicate with each other over APIs. For example, the user interacts with a web app written in React, editors maintain content in a headless CMS like Strapi, an Elasticsearch cluster adds search functionality, while credit card payments are handled by a serverless function using Stripe. You get the gist, the possibilities are endless. In a headless architecture, specialized components can be mixed and matched to create unique, immersive experiences.

Sounds nice, right? A happy family of services chit-chatting away. Yet, with a growing number of services, coordinating communication between services becomes more challenging. So, let’s look at the pros and cons of headless architecture. By the end of this article, you should be able to decide whether headless architecture is the right choice for your next project.

Pros and cons of headless architecture

Everything comes at a cost. So, let’s start with some of the challenges that you might face when adopting headless architecture:

Cons:

• Maintenance and infrastructure overhead: Multiple distributed services will most likely require more maintenance and infrastructure than a single monolithic application. When it comes to smaller applications, this overhead might outweigh the benefits of a headless architecture. Therefore, it’s worth having a close look at the required services and their infrastructure requirements. A headless SaaS CMS such as Contentful might add almost no infrastructure overhead. A self-hosted instance of Craft CMS will give you more flexibility at the cost of an additional server to monitor and maintain.
• Cost of brittle interfaces: Your services might be distributed across servers, even data centers, yet they are bound by the data they share. Simply put, changes to your interfaces — the APIs that services use to communicate with each other — can become costly. Imagine you need to touch and redeploy every service because someone decided to change a variable name. The Gang of Four says it best: “keep your interfaces closed for modification, open for extension”.
• Increase of complexity: It’s quite possible to run a thriving WordPress page without touching a single line of code, or for a single developer to run a successful web shop based on Shopify. While you are able to create immersive experiences with a headless architecture, you will need (a team of) capable engineers that combine different services, technologies, and programming languages into a working system.

Sounds challenging, right? Yet, there are plenty of reasons that justify the rising popularity of headless architecture. Let’s look at some of them.

Pros:

• Performance: Starting May 2021, Google will consider the core web vitals as a ranking factor, making page speed and time to interactive even more important. In a headless architecture, load times of under 100ms are not unheard of, even for large sites. Modern tooling such as static site generation and content delivery networks simplify serving fast, secure, and scalable applications. With performance affecting visibility on the web, it’s no surprise that the JAMstack is gaining in popularity.
• A single source of truth content: In a headless architecture, data is usually provided in a standardized format via an API. This gives you incredible flexibility on the consuming side, i.e. your customer-facing frontend channels. Think of a React app for the web, native iOS and Android apps, hey even a smart fridge. Headless (cold) beer, not so silly now, hey.
• Developer and marketing experience: A headless architecture lets you pick the tools that work well for a given task or business requirement. Equally important, a headless architecture allows your development and marketing teams to pick the tools that work best for them. Think of a development team that has great experience with React, React-specific tooling and even a component library that they reuse across projects. It’s no surprise that this team will be more efficient, let alone more motivated when using React within a headless architecture. In times when it’s more challenging than ever to attract talent, employee motivation is an advantage not to be underestimated.
• A growing ecosystem of headless services: There is a steady increase in Headless (SaaS) solutions. Jamstack.org alone lists 85 different headless CMS solutions. Add headless e-commerce, payment providers, search as a service, and serverless functions to the mix, and you will find yourself with a rich ecosystem of specialized services that can be combined to build rich, immersive experiences.

In a headless architecture, it’s not always about building a custom service for every business requirement. Rather, it should be a careful consideration between 3rd party SaaS solutions and custom functionality.

When to adopt headless architecture?

We covered the pros and cons of headless architecture. But how do you decide whether to jump on the hype train? Well, it’s important to weigh the decision’s benefits against its cost. We usually ask a set of questions to decide whether a project benefits from a headless architecture:

• Are there multiple frontend channels that consume the same data (e.g. a native app, a web application, and a smart fridge)?
• Is there functionality that benefits from decoupling into multiple services? (e.g. search functionality, credit card payments, image optimization)
• Can we reuse functionality from previous projects (e.g. frontend modules, services)?
• Do services in the architecture change frequently?
• Is the project large enough to justify the potential maintenance overhead?

Our take on headless architecture

As a digital agency, our take on headless architecture can differ between projects and customer requirements. Nonetheless, we found that the following tools and frameworks work well for us in headless CMS and e-commerce projects.

Frontend frameworks

In headless projects, we have full frontend-flexibility. Our frameworks of choice are Vue and React. Relying on modern frontend frameworks allows us to follow component-driven development and benefit from reusing components and entire modules across projects. Component-driven development helped us to significantly reduce development time per project.

Content Management Systems

TYPO3
At &why, we look back at a strong history with TYPO3, an open-source, enterprise-ready CMS. Before version 9, TYPO3 would have served as a good example for a monolithic CMS. Although TYPO3 includes a REST API for quite some time now, using it as a headless CMS required expert knowledge and a sizable amount of custom code. Not anymore, thanks to the TYPO3 Headless Initiative, it is simple to combine TYPO3 with Nuxt to create performant web applications.

Craft
Besides TYPO3, we have shipped headless projects using Craft, a flexible, user-friendly CMS that comes with REST and GraphQL APIs out of the box. We usually rely on Craft in smaller projects that benefit from a light-weight CMS.

Headless commerce
We have shipped headless e-commerce applications with Vue Storefront in combination with Magento and PIMcore. Recently, we have been experimenting with Next.js Commerce.

Wrapping up

At &why we strongly believe that headless architecture is here to stay. Done right, headless applications offer exceptional performance, a flexible scalable architecture, and a great user and developer experience. Yet, all good things come at a cost. Building headless applications usually requires skilled developers that connect and maintain distributed services.

Drop us a line!
We hope that our insights will help you decide whether to adopt a headless architecture for your next project. If you would like our help to decide, we are just a comment away.

Written by Jan Demmerle, Frond-end Developer at &why.