Gatsby and Drupal : Match made in heaven?

Gatsby is a popular static site generator that can communicate with any backend.

The front-end landscape has exploded in the last three years. Today you have various libraries/front end frameworks like React, Angular, VueJS. You have tightly coupled full stack frameworks NEXT, NUXT etc. Of all these options Gatsby finds a sweet spot with its JAM stack approach. JAMstack is “a modern web development architecture based on client-side JavaScript, reusable APIs, and prebuilt Markup.”

In this article we will discuss how we can make use of the JAM stack using Gatsby and Drupal. We will also cover the general questions that are generally not answered in the blogs.

1. Gatsby is static site generator, so what are the scenarios where I can use Gatsby.
2. My site has a lot of dynamic content, how do I make it work well with Gatsby.
3. I have read that Gatsby is based on React, so how can I decide when to use Gatsby and when to use React only front end.
4. Can I use gatsby to progressive decouple my Drupal website?
5. How can I configure Gatsby so that most of the configurations are read from the backend and a parity is maintained with current existing website.
6. What is server side rendering and how can I leverage it with my Gatsby and Drupal set up.
7. Is Gatsby good only for the anonymous user or can I leverage it for authenticated flows as well?
8. Setting up OAuth on Drupal and leveraging the same for Gatsby.
9. What is the relationship between jsonapi and graphql.
10. Setting up Gatsby
11. What are the other alternatives that play well with Drupal.
12. Should I use Gatsby or Tome?
13. Feedback

There are many todo articles that already explain how to get started with Drupal and Gatsby. I will just link to them here instead of repeating and answer the questions that I had when following them. If you have already made your decision just visit the Setting up Gatsby section.

What is JAM stack

JAMstack is “a modern web development architecture based on client-side JavaScript, reusable APIs, and prebuilt Markup.” In a crude analogy you can think of it like the static files deployment that you were doing if you were in software development say a decade ago. This is not entirely true but JAM stack tries to combine the ease of static sites along with the dynamicness provided by APIs.

Javascript : Javascript is used for the client side interactions, better handling of dynamic rendering of elements on the client side and also for interaction with the backend if any. Think AJAX.

APIS : Any interaction with the backend is abstracted into reusable APIs. One more advantage is that in the front end you can make use of your own APIs as well as any third party APIs.

Markup : You will using the Markup or HTML/css for the front end. In JAM stack markup is generally prebuilt at the deploy time.

Gatsby is static site generator, so what are the scenarios where I can use Gatsby?

Gatsby is a static site generator. What this means is that the public folder that is created during the build time will function as a static website. So you can take that folder and deploy it on any server with Apache or nginx like server to serve the requests. For example if you use the default starter kit of Gatsby communicating with Drupal backend, you only need the backend to be up during the build time. Once your build is done, you can down your Drupal server and just deploy the public folder generated during the build. What this means is that your Gatsby site will communicate with your Drupal backend during the build time, fetch all the details necessary and create static files for all the paths that will be present on your site.

My site has a lot of dynamic content, how do I make it work well with Gatsby.

Think of Gatsby as a state-machine. The state consists of the code changes you make and also the data you save in your database. So whenever there is a change in the code or the data in the database, you need to rebuild it for the latest state. For code changes it is easier to trigger the build. For the changes in database it is a little bit difficult. But you can make use of web hooks to trigger these builds. But the question is how frequently do you trigger your builds? Let us say that you can stay with some stale data, then you can have builds every few hours. This might be suitable for blogs where if the content is refreshed every couple of hours/days it should be sufficient. But if your site has lot of user interactions then frequent rebuilds might be a pain and it will also add load on the server. In such scenarios it would make sense to keep the content that changes less frequently in a backend like Drupal and for the content that changes frequently(like comments) it might be better to off load to a third party service(like Disqus for comments).

I have read that Gatsby is based on React, so how can I decide when to use Gatsby and when to use React only front end.

If you would like to have control of all your data(both that changes less frequently and more frequently) then it might make sense to do the Gatsby build for content that changes less frequently, then add React components that interact with live API calls for content that changes more frequently. Since Gatsby is built on React, you can stick to your standard API calls in componenentDidMount and then render the results in render function.

Can I use gatsby to progressive decouple my Drupal website?

If you are not sure whether to use Gatsby for the whole of your site, then this approach can be good. For example let us say that you have a website that has many functionalities including blog, you can just transfer the client facing blog functionality of your website to Gatsby. In your apache/nginx config just make sure that only example.com/blog is handled by your Gatsby front end and all other parts are handled by Drupal.

How can I configure Gatsby so that most of the configurations are read from the backend and parity is maintained with the current existing website?

One simple approach I took was to make sure that I have Drupal backend at backend.example.com and front end at gatsby.example.com

In my gatsby-node.js I added a rule like

result.data.allNodePage.edges.forEach(({ node }) => {
                    createPage({
                        path: node.path.alias,
                        component: staticPageTemplate,
                        context: {
                            slug: node.path.alias,
                        },
                    })
                })

This makes sure that even in the gatsby front end I can use the path set in the backend. So for example backend.example.com/blog/firstblog to gatsby.example.com/blog/firstblog This way it was easier for me to map and check the missing pages from the sitemap.xml as well.

What is server-side rendering and how can I leverage it with my Gatsby and Drupal set up.

Gatsby comes with a default SSR settings. What it means is that API calls to your data sources are made at the build time. So all the pages are server side rendered. Once you are done with a build you can pretty much shut down your backend unless you have any real time API calls that you need to do from your Gatsby app.

Is Gatsby good only for the anonymous user or can I leverage it for authenticated flows as well?

By default Gatsby plays well for read only kind of websites. But there is nothing that stops you from creating forms and authenticated user flows as it internally used React. Connecting Gatsby with Redux might be good for authenticated flows. Checkout https://medium.freecodecamp.org/how-to-get-started-with-gatsby-2-and-redux-ae1c543571ca for Gatsby with Reduct integration. If you want to add authentication to your Gatsby sites checkout https://www.gatsbyjs.org/blog/2019-03-21-add-auth0-to-gatsby-livestream/#authentication-in-gatsby

What is the relationship between jsonapi and graphql.

In Drupal jsonapi is a popular module. There is also a graphql module. But if you are using https://www.gatsbyjs.org/packages/gatsby-source-drupal/ plugin you will observe that on the Drupal end you just enable the jsonapi module thats all. What is happening is that the the GatsbySourceDrupal plugin is taking care of the jsonapi output and converting it to graphql compliant structure so that you can actually use graphql queries to access your data in Drupal. You are generally asked to enable the jsonapi access to all user. Be careful as you might be exposing some confidential data that is not intended. Do check these out before deploying in live.

What are the other alternatives that play well with Drupal?

Gatsby is a great tool. It makes starting with REACT and Drupal so easy. It is also highly configurable and customizable. But it can still be overwhelming for Drupal developers who have not worked with Frontend frameworks earlier. Thanks to open source we have other alternatives.

Tome is another interesting project that generates static sites for Drupal 8 quickly and without needing to know the new frontend libraries and tools.

In https://twitter.com/DrupalSAM’s own words

It’s important for me to make Tome more accessible to less technical users. Anyone that can make a Drupal site should be able to make a static site without learning a completely different toolset and programming language.

I think this is a great goal and will help the Drupal community immensely. Once people realize the advantage of JAM architecture I am sure most of the blog like sites will default to static sites :)

If you don’t trust me, just check out the video in below tweet to realize how easy it is to create static sites with Tome.

https://twitter.com/DrupalSAM/status/1091813197214928896

Should I use Gatsby or Tome?

As with most answers to the technical questions, that answer is “It depends” :P

But here is the thumb rule I use.

1. If you are not comfortable with Frontend and you just want to use JAM stack or static sites for the performance sake Tome is a great choice. There is not much addition learning curve.
2. If you want to leverage the fast pace of development in REACT eco-system but don’t want to build things from scratch, you can leverage Gatsby.

Setting up Gatsby

Before setting up Gatsby I would recommend going through the following two videos. They give you a high level insights and should be sufficient to get you started quickly.

Understanding Gatsby Internals for Drupal

If you would like to understand the details of how Gatsby works and how to customise it for Drupal, you can check out this blog by Ryan Bateman

Tutorial: GatsbyJS for Drupalers; or, How to JAMStack-ify your Drupal Site with GatsbyJS
GatsbyJS is everywhere these days. The upstart react-based site generator has come a long way from its humble…www.ryanbateman.space

Things I wish I knew in Gatsby before getting started

1. Gatsby also uses the term node. This is different from the node used in Drupal.
2. Any atomic data that Gatsby handles can be considered as node. So in Gatsby lingo Drupal nodes, categories, taxonomy terms and users can also be considered as nodes.
3. There is no rule that each Gatsby node needs to have a page. You can decide for which nodes you need to create pages.

Feedback

I hope this answers some of your questions before shifting to Decoupled Drupal site or deciding on the front end frameworks for your Drupal API backend. I have collected all these highlights and notes about Drupal/Gatsy using our extension. Once you do that, you can search all your notes from our dashboard.

If you have any questions that I am not able to answer just let me know about them in comments. We can explore them together and share our notes for mutual benefit. Let us make this as a repository for all the commonly asked Questions by Drupallers regarding headless option.