Headless WordPress with React, GraphQL and Gatsby

11/12/2019 by Rory Ashford-Bentley

WordPress, GraphQl, React and Gatsby JS logos

Mixd have over 15 years of experience developing enterprise level solutions for public sector clients. We have used WordPress as our preferred Content Management System (CMS) as it provides a very user friendly content editing experience and as WordPress’ popularity has grown, so has familiarity with it, and as such clients are very enthusiastic to use it.

Despite enthusiasm from content editors, if you were to ask web developers what they think of WordPress you will likely hear some less positive opinions of what it is like. This is largely because WordPress has not jumped on the ‘latest-and-greatest’ bandwagon of things that are considered best practice in the industry.

WordPress has made some substantial changes to the platform over the last few years; They introduced the WordPress Rest API and more recently they have overhauled the whole editing experience with the introduction of the Gutenberg editor.

These changes presents a progressive leap into the ‘modern web’ for WordPress who appear to be doing everything they can to shake off any notion that they are behind the times. As developers this is extremely exciting and allows us to radically change the way we approach developing projects in the future. As developers we now have complete freedom over how we define and build our frontend architecture.

Historic approach to WordPress development

I have personally been building WordPress websites for over a decade. The first WordPress website I ever built for a client is still live and has been running without fault since 2008. I think it’s fair to say that in 2019 we are largely using the same development stack that we have been using since 2008. Linux, Apache, MySQL and PHP (LAMP) are used to serve the website. Users visit the website and the WordPress PHP framework processes the user requests, fetches all the necessary content from the database and media library to serve the page. It’s straightforward, simple, efficient and extremely reliable but that doesn’t leave us with much room for innovation.

Benefits of this approach

Mixd have over a decade of experience working with WordPress

We know what works and what doesn’t and we have implemented solutions to these issues in our projects over the years with products like WP-Deploy which we developed to overcome the limitations of deployment via FTP which traditionally was the recommended way of maintaining a WordPress site. We were also the first agency to deliver a responsive website for an NHS trust.

Server-side rendering

WordPress is written in PHP. This means that web pages are generated server-side, this allows us to worry less about the functional capabilities of the older browsers we must support for public sector clients. It also means that the codebase is all conveniently kept together within a WordPress theme.

Extending core functionality with plugins

WordPress has a rich plugin ecosystem for extending the core functionality of WordPress. The official plugin repository has a rating system and a discussion forum so you can quickly establish how trustworthy each plugin is. We typically audit the plugins that we recommend to our clients and while we try to use as few as possible there are some incredible plugins that take WordPress from a basic blogging tool to a full featured CMS such as the incredible Advanced Custom Fields.

User management

User management in WordPress is great, it supports custom role delegation which we use for granting access to website administrators but also allows us to restrict access to certain areas of the site quite easily.

WordPress Gutenberg logo

Gutenberg editor

Gutenberg solves many of the issues that come from using shortcodes (a not so user friendly way of extending the content editor). It also relies heavily on Javascript frontend techniques and libraries.

Problems with current approach

It could be faster

For a long time we (in the WordPress community) have found ways to really optimise our theme development to make pages as quick as possible. We reduce the number of requests and compress images and frontend assets. We even take advantage of server-side technologies to squeeze every drop of performance out of the stock WordPress configuration.

One of the down-sides of server rendering is that for each page load a user must make a request to the server. The server hands the request off to PHP. PHP glues together a bunch of templates for various elements on the page and also has to make a series of requests to the MySQL database for the actual content. This process takes time and the user has to wait for all this before the page begins to load.

Jack of all trades mentality

Being a good WordPress developer is difficult. It’s very much a full-stack job role and developers (even juniors) are expected to be proficient in both frontend and backend disciplines and often it can even include elements of devops and hosting management. This leads to a tendency for WordPress developers to know the bits of full-stack development they have picked up using WordPress but not enough understanding to transfer those skills into other full stack roles. Similarly it means developers don’t get the opportunity to specialise and really hone their skills into either full stack, backend or frontend roles which isn’t inline with the industry as a whole.

You can’t escape Javascript!

Over the last few years there has been somewhat of a renaissance within frontend development. The traditional HTML, CSS and Javascript workflow is rapidly evolving. It’s now commonplace to find Frontend development roles that are heavily reliant on Javascript libraries like React, Angular and Vue.js.

WordPress has a target on its back

Being the most widely adopted CMS on the planet unfortunately means it’s one of the largest attack targets on the web. WordPress websites are commonly targeted for two reasons; Firstly, WordPress is predictable. files are always in the same place server to server so writing an exploit that can traverse the entire WordPress installation can be used on millions of potentially vulnerable sites. The second reason is Plugins. WordPress take security very seriously for the core product but they can’t and seemingly don’t take responsibility for the thousands of plugins out there and, without thorough vetting, there is no way of knowing with certainty that these plugins are safe. As a matter of due diligence, all the plugins Mixd use in production are vetted against our own internal stringent performance and security checks.

How Mixd plan to evolve

We have spent the last few months researching and debating how to evolve our ‘standard project’. Taking all of the great things we like about WordPress combining it with the new frontend innovations going on in the industry, we wanted to create a new workflow to take us to 2020 and beyond.

To further our knowledge and get some insight from key industry figures we attended JS Nation in Amsterdam this year. The talks gave us some great inspiration on how others are approaching frontend development and it was great speaking to other industry experts on the conference floor to get some detailed insight into their approaches and methodologies. Despite different libraries and frameworks being used, the common theme was that frontends built in Javascript are a great, scalable solution, perfect for Mixd projects.

We are extremely excited to see NHS Digital have released a javascript (nunchucks) component library. Not only does it include a range of components that can be used across all NHS sites but it gives us the validation that Javascript frontends are indeed a valid solution for public sector projects.

All of our industry research has led us to an exciting new development stack that will carry us beyond 2020 and we expect it to pave the way for the next 5 years. We spent the last weekend as a team together in Milan and during our company meeting over a few drinks we pitched the idea of change to the development team who, after hearing the following ideas, became extremely excited and inspired.

The new backend stack and workflow

Headless WordPress

Headless WordPress is the concept of running WordPress only as a backend. Posts and Pages are created in WordPress and the data from them can be accessed by the WordPress REST API. This allows us to host the backend and frontend of the website on completely separate servers which means that we can do much more to harden the security of the CMS.

By decoupling the frontend from the backend it makes it fairly simple for us to incorporate enterprise level functionality such as Single Sign On, allowing us to add a further layer of security for clients using Active Directory, Microsoft Office 365 or Google Apps who all offer SSO solutions.

graphQL logo


GraphQL as they say on their website is a ‘query language for your API’. It adds a lot of simplicity to working with an API driven data exchange and allows us to write simple queries to return only the data we need. There is an excellent GraphQL WordPress plugin to assist in serving and managing GraphQL data. There are also plenty of frontend solutions for interfacing with GraphQL. We can even map ACF custom fields to the API.


Something we couldn’t live without on our projects is the Gravity Forms plugin. Luckily they have a feature rich API that we can use to deliver forms to the frontend without a reliance on the CMS allowing us to move away from the pre-constructed markup that Gravity Forms provide out of the box in favour of our own controlled form markup making it much easier to make changes to improve accessibility and the overall UX.


We are really excited about solutions like Elasticsearch to go beyond what we can currently achieve. It’s something we are actively researching to ensure the best search experience all round. We are most excited about improving the quality of search results and the speed at which results can be displayed.


One of the benefits of separating the frontend and the backend of the website is that we don’t necessarily need to provision ultra high spec servers to accommodate for the backend and frontend traffic as the traffic to the CMS would be relatively low. Only content editors would be accessing the backend and data that is being served via the API will be using smart technologies for caching static assets on the frontend to massively reduce the overhead on the server.

Geolocation load balancing

We want to move our static assets such as imagery and media into regional Content Distribution Networks (CDNs) which will rapidly speed up load times on the frontend by serving content from the closest server to the end user.
A modern frontend for public sector

React JS logo
React components

React is one of the emerging Javascript technologies that frontend developers can’t avoid. It can be utilised in websites and applications. Its runs seamlessly in all modern browsers and allows for a new era of thinking when it comes to developing page templates and components.
Having used an ad-hoc server side PHP component loader of our own for the last few years the team are very familiar with the concept and React gives as several features that simply aren’t possible with PHP, such as state and lifecycle.


Another relatively new concept we have been exploring is the perfectly named CSS-in-JS. At first we were reluctant to even entertain writing CSS within our Javascript components but after testing and experimenting with the new possibilities it provides the frontend development team we have decided that its not dissimilar to writing Sass (preprocessed CSS) it’s just using a different language to do the preprocessing. From what we have observed it supports the majority of features that we rely on from Sass such as nesting and variables and gives us better alternatives (Javascript functions!) to Sass functions and Mixins.

We have been really enjoying working with Styled Components as our CSS-in-JS solution. It is architecturally a big change from Sass but we feel that the pros absolutely outweigh the cons.

Rendering static pages with Gatsby

We have been learning to develop with React for the last few years but we have always felt that too much reliance on JS potentially reduced the inclusivity of projects we were developing. Gatsby answers this call by generating static pages from Javascript components. The page can still be loaded and content can be read even with Javascript disabled within the browser . These pages have a really small footprint which means they can be loaded extremely fast. There is no server rendering at play delaying the initial page load so sites utilising Gatsby are incredibly quick when compared to our current server side PHP setup. Gatsby is also a Progressive Web App generator which means we can build in functionality for offline apps, push notifications and auto updating.


The Mixd development team are very excited to transition into this vastly new methodology and together over the next 6 months we will be heavily investing in research and development to solidify this approach before bringing this into production for our clients. Our desire and commitment to excellence remains unwavered so it is of the utmost importance that the solution has been rigorously tested.

Join us on this journey

If you have read this far and you want to work for a company that is innovating in these areas we are always recruiting for talented professionals to join our backend PHP (Laravel, headless WordPress and API development) team and our frontend team (HTML, CSS, React, CSS-in-JS, GraphQL).

Leave a comment