“Headless” and “decoupled” architectures are becoming increasingly popular in the world of web development. More and more organizations are choosing a headless option over a more traditional, monolithic architecture for benefits like increased performance, scalability, and more. While headless may not be the right fit for every organization, it offers many benefits and should seriously be considered for new projects.
The benefits and trade-offs of choosing a headless architecture vary based on the nature of the project, so we’ll look at them separately based on the project type.
Content-Driven Websites
Content-driven websites include projects such as: a marketing website for a brand or product, a news or blog site, or an informational website for a university.
- A headless architecture for a content-driven website would typically involve the following components:
- A Content Management System (CMS) - This could be a headless CMS such as Contentful or Contentstack, but many traditional CMSes like Drupal or Wordpress have APIs which allow them to be used as part of a headless architecture.
- Frontend Application, built with a Javascript framework that supports static rendering such as Next.js or Gatsby.
- A hosting platform such as Netlify or Vercel that specializes in hosting Next.js or Gatsby applications.
- A Search-as-a-Service platform, such as Algolia Search.
The biggest benefit of a headless architecture for content-driven websites is performance. For most content-driven websites, you will be able to statically pre-render most or all of the pages using a framework such as Next.js or Gatsby. This provides page load performance that outperforms sites using Varnish or a CDN for caching pages. This is because of a neat magic trick that frameworks like Gatsby and Next.js can pull off called static rendering. When a user visits their first page on the website, the server will deliver a pre-rendered HTML version of the page, along with a javascript bundle that contains the instructions for rendering other pages on the site. When the user hovers over a link, data for the next page will be silently fetched in the background. Then, when the user clicks the link, the new page will be rendered instantly using fetched data and the instructions in the Javascript bundle.
Depending on the implementation, increased security can be another significant benefit. For example if your site contains only static content, you could pre-render the entire site using a framework like Next.js or Gatsby and serve it from a CDN. Since the CMS only needs to be accessible from your build server, it could be locked behind a private network so it is not accessible from the public internet. Such a setup has a much smaller attack surface compared to a traditional CMS.
If you are building a content-driven site with a headless architecture, utilizing static pre-rendering or a hybrid approach that uses a mix of static pre-rendering and incremental static generation should be considered the default approach because of the performance benefits.
Outdated Myths and Perceptions
While we are on the topic of static sites, there are a few outdated myths and misconceptions from the early days of static sites that are still lingering around.
Myth #1: Static site frameworks are only good for smaller sites, as the build times are simply too long for websites with thousands of pages. This was more true in the past, but the Next.js and Gatsby, the two most popular static site generators, both offer a number of hybrid page rendering strategies that make this a non-issue. For example, for example, if you have 10,000 blog posts you could configure Next.js to only pre-render the 100 most recent blog posts at build time, and render the remaining posts “on demand” when a user tries to visit the page and cached for subsequent requests. This keeps your build times short, while preserving the benefit of lightning-fast load times for your most-viewed content.
Myth #2: Static sites are not able to support dynamic pages, such as a “My Account” page for authenticated users or a Search Page. Next.js and Gatsby both provide a few different ways to handle this. The latest versions of both frameworks allow for a server-side rendering approach on a page-by-page basis. So you can have a mostly prerendered static site with some select pages rendered server side where it makes sense. In case you’re curious, the “server-side rendering” is handled by serverless functions when you deploy your application to a hosting platform like Netlify or Vercel. The great part is that you don’t really have to think about this - as long as you follow the framework’s coding conventions it is handled automagically for you. Another approach is to simply build these pages with client-side javascript, and pull the dynamic content at runtime using API calls. This is how we usually implement search pages.
Myth #3: The content editorial experience is worse for headless sites. Early headless CMS implementations faced issues like clunky Preview experiences, where you would have to fill out the edit for a page, hit a “Preview” button, and wait for the static site generator to prepare a preview of the page for you. Now, many headless CMSes provide an instant preview that updates in real time as you add components to the page or add text to a field. Another past frustration with headless static sites was having to wait 10-15 minutes for the site to build after hitting “publish” before you could see your changes go live. Next.js and Gatsby now both have strategies for incremental static generation that can allow for near-instant page updates when configured correctly.
What are the downsides?
Now that a lot of the past problems have been solved, there isn’t a terribly long list of downsides when it comes to going headless for content driven sites, and they mostly have to do with cost effectiveness under certain circumstances.
Degree of Custom Development Required - A lot of the monolithic frameworks and CMSes have been around for a long time and have developed huge ecosystems of integrations, plugins, and modules. The headless CMSes and JAMstack which replace them in the headless world have not reached the same level of maturity. There are some projects we’ve looked at where we could build out a large portion of the functionality by simply installing and configuring off-the-shelf modules in Drupal, but building the equivalent functionality in a headless paradigm would have required extensive custom development. Even if the headless approach produces superior results, it may be hard to justify the difference in costs in these cases.
Current Skills and Expertise - If your in-house development team is already working with a more traditional, monolithic platform, switching to headless will involve a steep learning curve. Not only will it require learning a new architecture paradigm, it could also involve learning new programming languages, frameworks, and approaches to hosting configuration. This could slow down your team’s velocity significantly, and you’re also likely to make a lot of beginner mistakes your first time using a new technology. While it is important to give your development team opportunities to learn and stay up-to-date with the industry, your current project may or may not be the best one to use as a learning opportunity.
While there may be some project-specific reasons to stick to a traditional monolithic CMS, headless architecture should be seriously considered for most new content-driven website projects.
eCommerce Websites and Web Applications
eCommerce websites and web applications can benefit greatly from a headless architecture.
Scalability is a huge concern for these types of projects, as you will likely have a much higher volume of authenticated traffic. The amount of server resources required increases as the number of users increases, and you can’t easily solve the problem by just adding caching the way you can with a content-driven website.
Applications built with a monolithic architecture often need increasingly larger server instances to manage this traffic, which can be very costly. Adopting a headless architecture allows you to split your application into smaller and more manageable pieces, which can increase scalability and potentially save on hosting costs as well.
The architecture for headless web applications can vary greatly based on the needs of the app, but some things you would be like to see include:
- A frontend application built with a React-based framework, such as Next.js, Gatsby.
- One or more backend applications built with any server-side language, such as Node.js, PHP, or Java. The frontend will interact with these backend applications via API calls.
- Software-as-a-Service platforms. Depending on the application, this could include things like a Headless CMS, a Search Server, or a headless eCommerce platform.
- Cloud-hosted services, like AWS Lambda, S3, Simple Queue Service (SQS), etc.
Breaking up the application into these smaller pieces can greatly increase scalability and cost optimization. You can outsource the complicated details of infrastructure setup and auto-scaling by using a SaaS service like Algolia Search. And when you do need to build custom backend services, you can put them on much smaller cloud server instances that can scale up or down as needed based on user traffic. In many cases, this can bring down your hosting bills considerably.
Headless architecture can also provide additional flexibility in terms of design and user experience compared to some of the alternatives. For example, if deciding between building an eCommerce website using a BigCommerce hosted storefront, you are somewhat boxed in by the options its templating system provides. However, if you create a custom frontend application using BigCommerce as a headless service, you are going to get a lot more flexibility to customize the frontend experience.
What are the downsides?
Increased deployment complexity is one of the downsides of a headless architecture. Deployments are pretty straightforward on a monolithic application. You just move your code from your development environment to production and possibly run some database migration scripts.
In a headless architecture, you will have at least two separate applications that need to stay in sync with each other. You need to make sure that changes to your backend application do not break your frontend application. Figuring out how to handle these situations adds a lot of complexity.
Hosting configuration can also be more complicated in the case of web applications. In some cases, such as when you are only integrating a frontend application with SaaS services, you may be able to get away with using only a managed hosting platform such as Vercel or Netlify. However, in many cases the requirements of your headless-decoupled web application may require you to configure your own hosting on a cloud platform like AWS or Google Cloud Platform, which requires a pretty substantial increase of development effort.
Small, simple applications which do not need to scale, such as an internal company application that will never see more than a few hundred users will likely still be more cost effective to build with a monolithic framework.
It is also worth noting that static pre-rendering cannot be fully utilized on eCommerce websites and web applications, as they often need to display dynamic information such as custom pricing, inventory counts, user-specific data, etc. This means that some of the big selling points we covered for content-driven sites such as lightning-fast page load speeds or enhanced security are not necessarily applicable.
Conclusion
This article aims to provide a comprehensive understanding of the benefits and trade-offs associated with headless architecture. As you contemplate your next significant project, considering headless architecture is a wise choice. Remember, while it offers numerous advantages, it's essential to weigh these against your organization's specific needs and goals. If you're interested in exploring how headless architecture can fit into your organization’s strategy, feel free to reach out for a more in-depth discussion.
