2022 – The Year of Headless?

Don’t worry, we are fully aware that Halloween has passed and no, this blog post has nothing to do with Sleepy Hollow. This post is much more mind numbingly awesome than that. It’s about Headless Websites and how they are set to take off in 2022.

A Headless website is one that uses WordPress or other Content Management Systems to store content but relies on a single page application built on a javascript framework to serve the front end of the website to the user.

Headless websites have been on our radar for some time now, however until recently they were out of reach for the average small- and medium-sized business. In the past few years, however, the cost of entry into the Headless universe has dropped substantially making it a more attainable yet still adventurous undertaking for some businesses.

More and more we are seeing savvy clients ask about Headless sites, or point to Headless sites as examples of work they like. In particular, the performance of Headless sites is hard to argue with if you rely on a speedy website for your business needs. These sites might still be out of reach for most customers because of the need for a hefty development budget at the outset of a project. Increasingly, Headless sites are becoming a viable option for those who have specific needs that are not being met within the existing WordPress or other CMS themes.

I asked our Dev team for their thoughts on some of the technologies that are helping to make 2022 the year of Headless. Here’s what they had to say.

Shalaw Karim is one of our newest developers. He brings to the team past experiences working with React, Gatsby, WordPress and Strapi. He had this to say about React and Gatsby:

Why React, and why Gatsby?

  • Conventional Way (SSR) – PHP

In conventional websites like WordPress, if you click on a link, whether for a new page or a form, it sends an HTTP request to the server, which means every time we want to see something new, we have to wait for server response, that takes time, and often servers are not as responsive as we expect them to be. To solve this, often websites depend on JS libraries like Ajax, but for one thing, it is too much work, and often without much result as Ajax calls in WordPress should go through the hurdles of being authenticated through WordPress backend, and the structure of conventional websites are built to work with incoming, outgoing requests. This model is called Server-side rendering, because rendering any content requires calls to the server and possibly database. 

  • Modern Way (CSR) – React

React is a framework where it simply makes a virtual clone of your website (virtual DOM), and updates that clone through JS (not incoming or outgoing HTTP requests). It saves a blueprint of your website and handles changes (state update). Thinking about it, when you go to another page in React, you have not gone anywhere as far as the server is concerned, you are on a single page, working on a clone of your website. This model is called Client-side Rendering (CSR), because while the server is necessary, Javascript handles everything in the frontend. React also does data prefetching (when you open home-page, any link on home page will be fetched, like other pages, but not links inside them, like single posts), just to make it more user-friendly. Code splitting is another feature where you can make reusable components and write much fewer lines of code to achieve the same result.

  • Old but Gold (SSG) – Gatsby

– Then why Gatsby? React takes a blueprint of your current DOM tree, and handles everything through JS, that’s much faster than PHP, Ruby or Python, but not as fast or convenient or even secure as current business needs require. To solve that, the GatsbyJS team has made this framework on top of React where instead of a JS-handled clone, you have static HTML, CSS pages of your website. This is the oldest, but the fastest you can get with current technology as it’s simply a markdown with styles and some JS functions. The immediate question would be how GatsbyJS handles dynamic changes, for that, Gatsby produces the final result where thousands of static pages, with the latest data are built into them as if the data is static, minute by minute you can update and rebuild, so you wouldn’t want to be worried about the latest change in your backend.

Gatsby can deal with any sort of change, data update, form request, email, etc. There are some edge cases where you have to use the Server-side rendering model, where the requests from the user have certain changes that require server validation that can be handled with SSR, which Gatsby now provides.

It is more secure because what you have is pure HTML and CSS, and has nothing to do with database or server. You only need the database and server when you run build command. If you take the server down entirely later, the website will be functional and working correctly because the last version of your data is already integrated with your HTML and served statically. If the server is down, you can’t update it naturally, but it works with the last update, while with the conventional model, once the server is down, everything is down. This model is called Static-site Generation (SSG), and while there are many libraries and frameworks for this, Gatsby is the most popular.

Gatsby is also a hybrid model, because you can literally do SSR if you want, although it is not built primarily to work with SSR. You can also do Deferred-static Generation (DSG), which simply means the HTML is produced when the user makes a request, that makes the website faster.

The biggest downside to Gatsby is the build time. When you hit build, it could take minutes to build your website, and the bigger the website, the longer it takes. As of now, Gatsby has introduced incremental builds, where only the updated part will be rebuilt, which works not as fast as SSR when doing changes, but is much more convenient especially if the urgency of showing the data online is not the first concern. Unless you have edge cases like news websites, where any update should be immediately made public, Gatsby can take care of most of the business needs of today.

Blandy Castro another one of our new dev team members has also worked with React and WordPress in the past as well in the security and dev ops sector. She had this to say about GraphQL:

GRAPHQL – What does GraphQL do for us that is better than an API

GraphQL is a query language built in 2015 by Facebook to solve several problems they faced while building their APIs with REST. Here is what it can do better than REST API.

Pros:

  • Avoid over-fetching: If you make a call to show 20 titles of WP backend on your app, you might have fetched 20mg of data, but with GraphQL, it can be 2kb of data, as you avoid over-fetching by selecting exactly what you want without any over-fetching.
  • Avoid underfetching (using one query instead of two or three): Often when we deal with relational schemas, as when we want to show all orders of a user, we need two or three calls by REST to join them, but with GraphQL, all these calls can be made in a single query, which prevents under-fetching necessary data.
  • Type and schema based system to build a more solid API. While you can also use type system and schema with REST API, GraphQL has a built-in system to describe your schemas, which makes your applications much less error prone. If you want to make a post schema with title, content, status, and number of visitors, you will define that title is always a string (text) as well as content, but status is a boolean (true or false for published or  not) while the number of visitors is always an integer (number). This prevents any sort of invalid data input.
  • GraphQL is built to work not only between the backend and frontend as a regular REST or SOAP APIs do, but inside them, that’s why GraphQL does not only fetch data but also defines how we it is shaped in the backend and how it should appear in the frontend. This makes it more than an API, as its name suggests, a query language for your API.
  • GraphQL is fast and works well with modern technology like microservices and micro-frontends.

Cons:

  • GraphQL is new, and can be confusing to master, but it’s good that developers can work with a minimum amount of knowledge of GraphQL.
  • GraphQL uses a single endpoint to access all of your data, which means if for any reason your API is public, every node and edge of your API is open, unlike REST where you can make API endpoints public selectively.
  • GraphQL is a query language, not an ORM like TypeORM or Prisma. Developers cannot handle databases with GraphQL. While the integration might be confusing, it’s important to notice that GraphQL is a mere API-handler with the ability to determine the shape, type and structure of your data, nothing else.

Headless CMS options for React

We are currently building out some internal projects using React, Gatsby and GraphQL. We’ve got the front end covered but what about the Content Management system? Many of our internal sites and products are built on the WordPress CMS. Can WordPress be Headless?

Yes it can! and here are my thoughts on WordPress as a CMS for a Headless websites.

  • WordPress has featured a REST API for several years now, making it possible to manipulate WordPress data with interacting directly with the WordPress data base.
  • This API has opened the door for developers to start implementing new methods that make WordPress a much more flexible tool, including sharing data across domains or in our case using WordPress as the CMS for Headless websites.
  • WordPress is a familiar environment that is very easy for marketers and site maintainers to interact with. By sticking with WordPress for the backend of our Headless projects we are able to provide a familiar tool to our staff while still taking advantage of all the modern features Headless sites have to offer
  • WordPress is open source and has a huge dedicated development community. This community is incredibly resourceful and open, providing insight and solutions to WordPress users all over the world through forums and online communities.
  • WordPress’s parent company is all-in on Javascript. Several years ago Automattic the company that owns WordPress.com and maintains the free WordPress.org platform started incorporating more and more Javascript into its own products signalling a shift for the WordPress development community from php to Javascript as the primary language that all WordPress developers must know. The shift lays the groundwork for Headless sites to become the norm rather than the exception for WordPress websites in the future.
  • Scalability, we love that with tools like the WordPress REST API, and plugins like WP Graph QL that we can take a previously developed WordPress site and scale its data to work with modern technologies like React and Gatsby.

Seonah Han has been with Glacier Media for several years now, working on a variety of projects across the company. One of these projects, Flyerstory, was built using the Strapi CMS. Here is what Seonah has to say about Strapi.

  • Headless CMSes are versatile tools that can be used for various application’s architecture. You can manage and administer information to be consumed from different devices, platforms, and services.
  • Strapi is an open-source headless CMS to connect your Front-end with Strapi’s Back-end with API. It provides a user-friendly CMS interface ready with short time-to-deploy. Developers with a strong background in the front-end with little knowledge on the backend can shine with a tool like Strapi.
  • It is an open-source, free to use software.
  • You can integrate with other software and custom apps like React, Vue, Nuxt.js, Next.js, Angular, Svelte, Sapper, and Flutter.
  • You can define content relations like link articles to authors, categories, and tags, which makes it a great CMS tool for blogs and media sites as well as managing product informations.

Naomi Papequash has been with GMD for a year now. In her time here she has expanded on her past experience in the e-commerce industry to become our in-house Shopify expert. She had this to say about the prospect of building Headless Shopify sites with Shopify’s new Hydrogen framework.

Shopify In A Headless World

  • As Shopify continues to expand, it’s offering more ways to customize storefronts, including expanding into the world of true headless commerce. Shopify recently launched a developer preview of its new Hydrogen front-end development framework, and software development kit.
  • There haven’t been headless solutions built specifically for e-commerce, and Shopify is working to fill that gap with Hydrogen, available with Shopify Plus.
  • Hydrogen will streamline the process for creating custom storefronts from scratch, and with the implementation of webhooks, your storefront easily connects to Shopifys ecommerce functionality
  • Shopify’s hydrogen is based on React and javascript, allowing developers to move away from reliance on Shopify’s Liquid programming language and stack, which can sometimes lack flexibility.
  • Shopify is also leveraging a newer technology in Hydrogen called React Server Components which means pages will download much faster.
  • Will allow integrations of innovative technologies like augmented reality try-ons,  natively through Shopify rather than a third-party software.

If you’ve made it this far you are obviously very curious about Headless websites (and patient to boot). While Headless sites are nowhere near to taking over the market in the coming year, we do expect that 2022 will be the year that Headless sites start to make major inroads. We have seen that several technologies are fuelling this trend. In particular React, and GraphQL are making it possible for developers to use several different Content Management systems to build easy to maintain and highly functional web applications. The buy in that we are seeing at a corporate level from companies such as Automattic and Shopify suggests that this is a trend that is nowhere near dying out and will likely take over huge segments of the web.