Getting into Gatsby

31. August, 2020 6 min read Gatsby

Creating Gatsby powered websites

It seems like we are going back in time, building static websites without server-side code or database – introducing Gatsby.

Gatsby is a framework that builds upon the modern React library. Similar to Next.js, it aims to provide accessible tools for developing static progressive web apps (PWAs).

It’s easy to get into it – if you know your React – and helps you to build fast and reliable websites that consume little resources.

Gatsby is a free and open-source framework based on React that helps developers build blazing-fast websites and apps. gatsbyjs.org

This article summarises my experience building the following three websites using Gatsby:

I also do not intend this to be a step-by-step tutorial on how to get started with Gatsby. For that, have a look at Gatsby’s excellent quick-start documentation.

Getting started with a starter

Yeah… I just promised that this is not going to be a step-by-step tutorial, though I have to mention the fantastic starter projects Gatsby provides.

There you find over a hundred different opinionated Gatsby setups using best practices and plugins. You can quickly bootstrap these from the Gatsby CLI.

We at Divio, used gatsby-universal as an initial starter project to create flavours.dev. It is still a great starter. However, today I would recommend gatsby-advanced-starter, as it offers more robust integrations and is actively maintained.

Know your React

Gatsby is based on React; as such, it is imperative to know React before trying out Gatsby. So head over to reactjs.org, go through the tutorial and create a few sample React apps. You don’t have to be a React developer with ten years of experience to handle Gatsby, but at least familiarise yourself with React before giving Gatsby a spin.

If you have already ten years of experience, let me know where you got those, considering React was released in 2011. Alternatively, if you are fluent in React, try setting up a Gatsby project from scratch and integrate Typescript. It is a great combination. We did that while developing divio.com, and it was fun 🥳.

Taking the first steps

So why did we choose Gatsby over a traditional content management system? Well, because flavours.dev seemed to be a straightforward one-pager project with some content/assets and we wanted to have some fun with new technologies on Divio Cloud.

We also needed the website to be super fast and responsive (the fast one), which is hard to achieve with dynamic content.

Though our journey wasn’t without problems, obviously, best practices still need to be applied when dealing with the front-end code. Also, SEO needs to be spot on, by knowing which code to optimise where. That is where the starter helped us at the beginning but turned sideways once we needed to add further customisation.

Some originated from not understanding how GraphQL worked in Gatsby’s context. Gatsby uses Page Queries and Static Queries through either the <StaticQuery /> component or the useStaticQuery hook. Just the sentence alone stirs up headaches. You have to know when to use what to avoid side-effects. Find out more on the Gatsby documentation if you want to dig into the differences.

I also had to get used of the concept of <Helmet> at the beginning. It’s powerful, and you can extend your pages easily with additional markup such as meta tags to enhance SEO. Many starters leverage Helmet, but you have to wrap your head around the implementation of each.

Another issue we faced often was the cache. While gatsby develop offers an excellent development environment, it’s far from perfect. Even gatsby serve has its short-comings, and you always need to re-run the command to get to a testable state. Nothing beat testing on the production server at the end.

We achieved a pretty remarkable result whilst keeping best practices in check, all thanks to Gatsby’s wonderful tools, plugins and community:

Speed score from 31st of August 2020 using Lighthouse
Speed score from 31st of August 2020 using Lighthouse

Taking the next step

Once we finished our first project, we eagerly wanted to convert divio.com as well, with the following goals in mind:

  • We wanted Typescript with Gatsby to share code between the marketing website and the Control Panel.
  • Add further linting and automation tools to cohere with the standards from the Divio Cloud.
  • Improve the deployment process, to automatically deploy to Test/Live on Divio Cloud when a Pull Request is merged to master/develop.
  • Find a way to integrate the Blog system into Gatsby.
  • Use Storybook to share stories.

divio.com was undoubtedly a larger project. We had to migrate a substantial amount of content from the existing website into the new one.

For this, we converted most content into Markdown files and loaded them through GraphQL. We did little experimentations already on flavours.dev but now we had to build a more robust system. We could have also integrated other tools such as Contentful. However, we choose to use a more minimalistic approach.

We practised the same approach for the Blog as well, basically migrating them to single Markdown files with an appropriate folder structure to source them through GraphQL.

The integration of Typescript, additional linting and deployment tools were pretty straight forward. The deployment bit was a bit more complicated, so I’d like to share the code for future references:

# .gitlab-ci.yml
image: node:latest

stages:
  - Build
  - Deploy

build:
  stage: Build
  script:
    - npm install
    - npm run build

deploy:
  stage: Deploy
  before_script:
    - npm install -g @divio/cli
  script:
    - echo ${DIVIO_DEPLOY_KEY} | divio login
    - divio project:deploy live --remote-id ${DIVIO_APP_ID}
  rules:
    - if: $CI_COMMIT_BRANCH == "master"

Diving deeper

I still followed the same principle when creating my websites. Most of the code was shared back and forth between the Divio marketing website and my own.

We added nice animations through Framer Motion, loaded data dynamically via APIs, worked with form validation and submissions, added page transitions, played around with gatsby-image, leveraged Gatsby’s Node API and even added automated tests.

You can even subscribe to my Blog using an RSS Feed. All hosted neatly on Divio Cloud with fast responses and fantastic support (cough 🤷).

It has been an incredible journey so far, and I’ll keep using Gatsby, for now. If you’d like to hear more about implementation details or have some questions, let me know. ‘Till next time!