Headless architecture has recently risen in popularity, and with good reason. Its flexibility, performance, and power directly address the needs of users who expect truly impressive features to load quickly on any device. The downside is that the learning curve around planning and executing a headless site can be daunting for beginning and experienced developers alike.
Alley has been building headless sites for several years and, in this article, we will pass along some valuable lessons that can help you when you’re considering going headless for the first time.
Be intentional about your choice in approach.
A headless application is one where a front end – usually in JavaScript -gets its data from a CMS via an API endpoint. This is in contrast to a monolithic application where the CMS and front end are inseparable, or coupled. A traditional CMS has its front end, also called the head, coupled to the rest of it. A headless CMS does not. For that reason, sometimes a headless CMS is also referred to as a decoupled CMS.
A monolithic CMS remains a prudent choice for many projects. Traditional blogs, brochure sites, portfolio sites, and small sites with low traffic can benefit from the built-in features of a monolithic CMS and may not see tremendous benefit from a headless approach.
But sites with complex content, high traffic, or innovative features can realize the benefits of headless in powerful ways. A couple of recent examples of headless sites include Fortune and Colorado Public Radio. Our rebuild of Fortune as a headless application decreased page load times by 60%. The redesign and rebuild for CPR included a persistent audio player that stays with the user while they navigate the site; an elegant feature that is possible via a headless CMS with a React-based frontend.
Ensure your team is prepared.
It’s also important to take into account the skills and experience of the team building the project. The rigidity of a monolithic CMS can provide guardrails against risk. The CMS has made decisions or provided strict guidance around code structure, deployment, SEO, design systems, etc. With a headless CMS, those guardrails disappear. The team has the freedom – and responsibility – to make choices around nearly every aspect of the project. It’s like the difference between driving an automatic and driving a stick shift.
Divide work into vertical slices.
Many people say that one advantage of headless architecture is that it can allow efficiency through specialization. Since the back end and front end of a headless site each have their own codebase, developers can focus on their strengths. Building a headless site with the two working in isolation is possible, but at Alley we’ve found that a more effective workflow strategy is to divide work into vertical slices where a ticket includes whatever changes are needed to each code base such that progress is realized. This approach can lead to fewer bottlenecks, improved developer velocity, and a shared sense of ownership over both codebases.
Build up your endpoint expertise.
Another important aspect of headless sites is the role of API endpoints. An API, or application programming interface, connects two systems to each other. In the case of a headless site, the API connects the CMS to the front end. An endpoint is a specific location where the front end requests and the CMS responds with data.
The structure and content of the data in the endpoints are specific to each API. Learning to make sense of and manipulate endpoints is an important part of working with headless sites. Endpoints that exclude valuable data negatively impact performance, since calls to additional endpoints are needed. However, endpoints with extraneous data can cause their own headaches.
In fact, the structure and content of the data in the endpoint have such a profound impact on the way that a headless site is built that Irving, Alley’s open-source ecosystem for building enterprise-level headless projects, includes purpose-built APIs that mirror the structure of a React component tree.
Employ a modular design system.
Shifting from a monolithic CMS to headless also means that design is no longer dependent on templates; rather it can be based on a modular design system, such as Brad Frost’s Atomic Design. Breaking down a design into modular components that can be reused in many ways can help make code more robust and consistent.
Conceptualizing content as components reflects how sites are designed today. A 30,000 page media site may consist of a handful of content pieces arranged in a few different layouts that can be perceived on a practically infinite number of devices, not all of which involve screens.
Going headless for the first time can be overwhelming as it may be a totally different approach to building a website. Being thoughtful about your choice of architecture and making shifts in the way that you approach the project can help you adapt quickly and ensure that your first headless project will be a success. If you’d like to learn more about the process, our headless toolkit Irving, or anything else, reach out on Twitter or through our contact form!