Bake a decoupled starter Gatsby pie with Drupal filling.

Stew West / May 24, 2022

This blog post aims to describe, at a meta-level, how to decouple Drupal with Gatsby on the frontend, in various ways. We will also guide you as to how to sprinkle some custom ingredients for extra goodness. Before we begin, I must tell you I had dreams about this title. Does one say it's a Gatsby Pie with a Drupal filling or a Drupal pie with a Gatsby Crust? Either way, hopefully, it tastes the same 😉

We'll Look At These Plugins

Gatsby-Source-Drupal
Gatsby-GraphQL-Toolkit
Gatsby-Source-GraphQL (and, why not this one)

With the various Gatsby source plugins, one needs to consider the pros and cons of each recipe.

We'll discuss benefits and caveats such as caching and scaling sites that use many Paragraphs types with nested content. We won’t do step by step install instructions, as those are in the various repos, but we will point you in the right direction.

Let’s just prepare ourselves. Decoupling Drupal is exciting and at the same time, a daunting task. When we remove the Drupal frontend, we need to handle and recreate basically everything. So we need to plan this out as we no longer have Drupal forms or validation, nice friendly public/private file URLs or authentication (if you need to have users logged in to edit their profiles etc).

Considerations

You also need to consider how you’ll host the Drupal backend and then how you will build and host the frontend.

Lastly, you’ll need to set up a fast “live” preview of content changes for editors.

We are not going to talk about the logged in Admin theme UI in this blog post. See this Admin UI Javascript initiative for more.

Remember, Gatsby is a static site generator ++. In Drupal, when you edit and save a node, it is generally visible immediately to the public (perhaps not as quick if there is serious caching going on) but you know what I mean.

With decoupled Drupal, when a node is edited, we need to tell the build system about the change, this then runs a new build, which pulls in all or only new content (see incremental builds) into Gatsby’s GraphQL node store, from a source (in this case Drupal JSON:API or GraphQL endpoint).

Gatsby then renders each page’s HTML. Once all the pages have been generated, these files are uploaded to a host and that build version is made live automatically or manually. Depending on the method and ingredients you use, this can take a few minutes or a lot more minutes++.

So you need to consider this in your decisions and processes. For you, the site’s speed may be more important for visitors than the backend editorial experience, as in the time it takes for the editors to preview new changes and see them go live.

Services - Services Everywhere!

We’ve used various combinations and can recommend either going the full Gatsby Cloud route for building and/or hosting, or self-hosting the build on Lagoon (via amazee.io) and then uploading the build to Netlify (which you can also do from Gatsby Cloud). There are many more options, so it's recommended to do some research to find out which will work best for your needs and budget.

Some obvious wins are that Gatsby is super fast and it's very secure as it's a “static” site. Combine this with Fastly CDN and you’ve got lightning!

Developing with Gatsby/React with GraphQL is also a great developer experience. If the maintenance team is doing backend updates or the backend server is restarted for some reason, the frontend is not affected by it during the maintenance period (unless you're doing realtime isomorphic fetching of data from said Drupal server).