A Front-end Developer's Thoughts on Headless Architecture

The headless approach gives you the freedom to present content no matter the device, the power to choose and change development tools and the possibility to implement immediate visual changes!

Within a headless architecture (or decoupled architecture), the backend is separated from the front end and is responsible for storing and exposing data via API endpoints. Because the backend and frontend are separate, the part that users see (the visual presentation part) is the job of the frontend developer. 

A headless approach changes the development team dynamic, too. For frontend developers like me, it means no more backenders altering templates and no more waiting for the views integration!

*Developers all over the world cheer in unison!*

Today, the front-end developer role requires a broad skill set and a keen drive to stay ahead of the latest front-end trends. What was once needed was simply top-tier technical skills and an eye for design and user experience; you must stay updated with the latest modern frameworks and trends as user expectations and headless become more widely adopted.

We always remember the good old days as simple times. But is that the case for front-end architecture? 

Fifteen years ago, front-end work was pretty straightforward and reasonably schematic. Most projects relied on basic HTML, CSS and JavaScript. https://jquery.com/, and no one cared about preprocessors or transpilers and frameworks like Angular started becoming interesting!

As the years have progressed, the possibilities of front-end technology have exploded. Backbone, React, Vue, Svelte, Grunt, Gulp, Webpack, Snowpack, CSS grid, CSS variables, Tailwind. These are just a few tools, frameworks and libraries that have changed how front-enders' work (and how complex their work is).

The number of possibilities to deliver content to the user has grown dynamically, too. Websites are no longer the single source of information. Mobile apps, readers, VR or wearable devices joined the ecosystem of mediums for providing world content. This is great for users because they can access information wherever they need it and on any device. This omnichannel approach can create potential problems for companies. They may need to either build separate content platforms for each channel or use a headless/decoupled approach to serve data to all channels. 

That sounds great, right? At first sight, yes. But there are some potential pitfalls, so let’s gather into simple pros and cons (in my humble opinion)

Pros of headless architecture

Development independence

Most front-end developers value development independence and flexibility when using a headless/decoupled approach.

What does this mean?

Within headless architecture, the backend does not generate any views, so frontend developers have the freedom to choose whatever tool, programming language, or framework they want to use to develop the visual side of the application or website. Love to work with React? Excellent - you are free to do so. Do you just want to use Snowpack instead of Webpack? Not a problem at all. 

When you start a project, you can choose what suits you best! Of course, your choice may sometimes be limited by company guidelines, project-specific demands, the stage of development or business requirements. But generally speaking, there is much more freedom to select your tech stack for the front end. 

More flexible development options can be beneficial for businesses, too. In the fast-changing technology environment being “stuck” with outdated tools and frameworks can lead to demotivation and frustrations, resulting in a workplace that doesn’t enable teams to develop their skills fully.

Flexibility

Unlike traditional monolithic software architecture, a headless approach gives more flexibility when creating visual parts for the backend data. This is a crucial factor nowadays since the content can be presented through multiple mediums like websites, mobile devices or internal POS screens.

With headless, frontenders can focus on building fast, user-optimized visual interfaces for every required device without worrying about the current backend stack. This new flexibility means that projects don’t have to rely on specific plugins, extensions or custom 3rd party integrations (or one specific CMS, for example). Developers can use every data service available to build powerful and effective content presentations!

Speed

Quickly responding to market changes or user requirements can be crucial in digital business. Based on analytics or user interface tools, we know precisely what part of the page should be modified to improve conversion rates or when to take an unexpected business opportunity. 

As I mentioned above, content is no longer tied to CMS themes or templates, so any change to the user interface does not require time-consuming integrations. 

Speed is also crucial for resolving issues. With Headless, the bug-fixing process can be done quicker without engaging too many people within the development team. 

Scalability and compatibility

The front-end's scalability means that the code can be written as separate, small, independent, easily maintainable, manageable and customisable parts. With headless, this is pretty straightforward since everything is written without unnecessary CMS templates or theme output limitations. This makes it easier to create standalone components and services that can be reused and modified quickly. 

Decoupling from the backend code also means that on the front side we can easily add new features and 3rd party integrations and take advantage of all the tools and services that let our platforms stay up-to-date and flexible.

Security

In traditional monolithic architecture, frontend updates and upgrades usually depend on the global platform (e.g. CMS). Security patches for frontend plugins or libraries often can’t be done quickly since they are shared with backend code and require additional compatibility checks. With a headless/decoupled approach, frontend updates can be done separately and instantly. Plus, the frontend code is not affected by backend vulnerabilities!

Cleaner code and project structure

From a frontend perspective, there is a better separation of the frontend and backend code. In the traditional development process, HTML, CSS and JS are often implemented within backend views, templates, and theme file structure (or sometimes hidden in the backend code). This can be a nightmare, especially when the CMS or other platform has multiple views directories or complicated extensions. Decoupled frontend code solves this issue and allows a better understanding of all dependencies for the project architecture. Usually, the frontend code structure is typical for applied frameworks or chosen templating systems, which speeds up the development process. 

The downside to headless architecture

Unrealistic expectations

When switching to headless architecture, a common issue is that companies forget that its primary rule should be API first design. When considering content, managers and editors can sometimes expect the same content editing flexibility or focus only on a single medium (like a website). Some users are also used to out-of-the-box solutions, so it can be hard to accept that there is no quick preview or accessible theming possibilities. 

For developers this can create additional pressure and unrealistic development time expectations for front-end developers. 

API design issues

Another problem can be that frontend developers are often not involved in designing API or endpoints for headless projects. This way, they end up with a data structure that is overly complicated or insufficient for developing custom designs and providing a proper user experience.

This is also an issue when a company uses an existing headless platform (CMS, ERP, etc.). How the API for that product is designed may be hard to implement. Another issue is that sometimes the documentation for the API is very limited or the external software might not provide all the needed functionalities.

Content flexibility challenges

One common objection against headless projects is that the content flexibility is very limited. Grid and content blocks are not easily manageable compared with the traditional approach. Frontenders may struggle with element positioning and adjustments when writing code (but this is mainly caused by poorly prepared APIs). Headless platforms increasingly try to implement custom grid solutions, enabling easy theming and possibilities to create preview modes.

Testing

Providing content to multiple devices requires the usage of different frameworks and applications. This means the testing process can be complex and time-consuming. We write code for every medium we need for separate testing scenarios and different testing tools and frameworks. 

A headless approach changes a lot within front-end development. 

At times, it can be challenging to adapt to a new way of formatting content or to deal with the increased time it takes to create visual parts of the application. Plus, there’s the fact you need to write multiple templates and tests for different devices.

With all that said, the independence from backend integration and flexibility when choosing tools and frameworks makes Headless so popular and loved by front-enders like myself. Whether you’re a frontend or a backend developer, i’d love to hear your thoughts on the headless or decoupled approach and what it means for you.