Is headless really that straightforward? Let’s take a look at some pros and cons of headless or decoupled approach from the frontend perspective
Innerworks is coming soon...
This blog was originally published on our previous Cogworks blog page. The Cogworks Blog is in the process of evolving into Innerworks, our new community-driven tech blog. With Innerworks, we aim to provide a space for collaboration, knowledge-sharing, and connection within the wider tech community. Watch this space for Innerworks updates, but don't worry - you'll still be able to access content from the original Cogworks Blog if you want.
A headless approach in web development seems to be the “holy grail” for some frontend developers. The approach gives them the freedom to present content no matter what the device, the power to choose and change development tools and the possibility to implement immediate visual changes.
Sounds too good to be true, right? But is headless really that straightforward? Let's take a look at some pros and cons of headless or decoupled approach from a frontend perspective.
The good old days.
Fifteen years ago frontend work seemed to be pretty straightforward and fairly schematic. Most projects relied on basic HTML, CSS and JavaScript. jQuery was the king, no one really cared about preprocessors or transpilers and frameworks like Angular started becoming interesting!
As the years have progressed the possibilities of frontend technology have exploded. Backbone, React, Vue, Svelte, Grunt, Gulp, Webpack, Snowpack, CSS grid, CSS variables, Tailwind. Just a few of the many tools, frameworks and libraries that have changed the way frontenders work (and how complex their work is).
The “typical” backend developer is no longer able to find himself quickly in this advanced tech stack. The entry-level for frontend work is definitely higher than in previous years!
The number of possibilities to deliver content to the user has grown dynamically too. Websites no longer are the single source of information. Mobile apps, readers, VR or wearable devices joined the ecosystem of mediums used for providing content to the world.
This is great for users because they can have access to information wherever they need it and on whatever device. For companies, this omnichannel approach can create potential problems as they may need to either build separate content platforms for each of those channels or use a headless/decoupled approach to serve data to all channels.
Headless architecture explained (in a nutshell)
Within a headless architecture (or decoupled architecture), the backend is separated from the frontend 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 (mostly). A headless approach changes the development team dynamic a little too. For us frontend developers, it means no more backenders altering templates, no more waiting for the views integration!
That sounds great, right? At first sight, yes. But there are some potential pitfalls so let’s gather them into simple pros and cons.
Pros of headless.
Development independence.
Most frontend 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 freedom to choose whatever tool, programming language and framework they want to use to develop the visual side of the application or website. Love to work with React? Cool - you are free to do so. Just want to use Snowpack instead of Webpack? Not a problem at all. When you start a project you have the power to choose whatever 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 frontend.
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 fully develop their skills.
Flexibility.
Unlike traditional monolithic software architecture, a headless approach gives more flexibility when creating visual parts for the backend data. This is a key 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.
In digital business, quick response to market changes or user requirements can be crucial. Based on analytics or user interface tools we know exactly what part of the page should be modified to improve conversion rates or when to take an unexpected business opportunity.
Like we 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 and without engaging too many people within the development team.
Scalability and compatibility.
Scalability of the frontend means that the code can be written as separate, small, independent parts that are easily maintainable, manageable and customizable. With headless this seems to be pretty straightforward since everything is written without unnecessary CMS template or theme output limitations. This way it is easier to create standalone components and services that can be reused and modified quickly.
Decoupling from the backend code also means that on the frontend 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 are usually dependent on the global platform (e.g. CMS). Often security patches for frontend plugins or libraries 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 parts are often implemented within backend views, templates, theme file structure (or sometimes hidden away in the backend code). This can be a real 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 framework or chosen templating system so it speeds up the development process.
Cons.
Unrealistic expectations.
A common issue when switching to headless architecture is that companies tend to forget that its primary rule should be API first design. Managers and editors can sometimes expect the same level of content editing flexibility or are focusing only on a single medium (like a website) when thinking about content. 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 easy theming possibilities.
For developers, this can create additional pressure and unrealistic development time expectations towards frontend developers.
API design issues.
Another problem is can be that frontend developers are often not involved in the process of designing API or endpoints for headless projects. This way they end up with a data structure that is overly complicated or not sufficient for developing custom designs and providing a proper user experience.
This is also an issue when a company decides to use an existing headless platform (CMS, ERP etc.). The way 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 simply 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). More and more, headless platforms try to implement custom grid solutions, enable easy theming and possibilities to create preview modes.
Testing.
Providing content to multiple devices requires usage of different frameworks and applications. This means the testing process can be complex and time-consuming. For every medium, we write code we need for separate testing scenarios and different testing tools and or frameworks.
Final thoughts.
A headless approach changes a lot within frontend 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 of that said, the independence from backend integration and the flexibility when choosing tools and frameworks is what makes headless so popular and loved by frontenders everywhere (me included!)
Whether you’re a frontend or a backend developer, we’d love to hear your thoughts on the headless or decoupled approach and what it means for you.
Arek