A Look Back at a First Year of Using Gatsby JS.

Tom Parsons
Feb 3 · 5 min read

I’ve been working on an application built on the Gatsby framework for a little over a year now, and have had an excellent time doing so. There have been a number of problems (mostly solvable), and a boatload of features and plugins that have saved more time than I can imagine. So in general, it was a good year, here are some of the ups and downs…

(Ups & Downs right?) Photo by Kenniku Tolato on Unsplash

Some context; The application I manage is a reasonably sized, reasonably complex, multi product, multi locale, web application. With a full team of engineers, product managers and designers, all working together to build and manage the best application we can. We started using Gatsby as our principle framework at the end of 2019, primarily for its Server Side Rendering (SSR) capabilities, and it has since grown into a full-blown application.

Let’s start with some positives, and then a negative, and then some positives. I believe there’s a technical term for this…

Positives

I think by far the most useful and expansive feature I have found is the Contentful Plugin — as we use Contentful for our content, having a plugin that auto generates a GraphQL schema that requires zero management, and everything just works out of the box; Whoa.

Woah.
Indeed Wayne, Indeed Garth.

Using the createPages functionality of Gatsby, along with templating, has provided the ability and control to manage our content in a frictionless and manner, whilst maintaining the benefits of SSR.

This set of features, each of which is a big positive in my opinion, combined, has created an incredibly easy to use, scaleable, and reliable application.

Easily being able to add our own things when we need.

I suppose this is sort of obvious, but we haven’t really been limited by Gatsby, or at least we haven’t surpassed its limitations yet, will we?

For our content and requests that can’t be server side rendered, we use various tools such as Axios and Amplify; adding these services was no more complex as it would be to add to any existing architecture, allowing us to have a combination of both SSR, and real time data requests, so dreamy.

The Main Negative

If you’ve used Gatsby extensively, along with GraphQL, you may have come across this; passing props into static GraphQL queries. This isn’t a deal breaker of course, I’m not diving down a webpack rabbit hole to solve this problem, we have workarounds. But, we could remove some code; functions etc if this problem was solved, which would be nice.

My issue with it is that because we can’t always use props in the queries — specifically staticQueries (which are necessary), we miss out on being able to use some of GraphQL’s features, which in turn sort of renders the GraphQL query somewhat useless.

Some Pseudo code to illustrate:

const locale = "en-GB"const query = useStaticQuery(
graphql`
query {
allItems {
node_locale
...whateverElse
}
}
}`
)
return allItems.filter((item) => item.node_locale === locale);

And here is what would normally be expected using GraphQL

const locale = "en-GB"const query = useStaticQuery(
graphql`
query($locale: String!) {
allItems(filter: {node_locale: {eq: $locale}}) {
node_locale // (not needed any more)
...whateverElse
}
}
}`
)
return allItems;

Because this code is used with SSR, the queries/logic are run at build time, so it actually doesn’t cost us much. So practically it’s not that bad, but at scale you can see why it can become problematic.

There’s some docs and issues on this, and far be it from me to complain about a feature that I’m sure has SO MANY good reasons for why it’s not a simple thing to implement!

If we’re asking for things, could we have a Gatsby — Phrase plugin too. That’d be helpful.

But loads more Positives

  • TypeScript. I love TypeScript, it was very easy to migrate from prop-types et al to .ts/.tsx within the Gatsby eco system.
  • Ease of deployment. When I first tried Gatsby, as a personal project, deploying the site via Netlify was yet another frictionless part of the process.
  • Inspirational Plugin library. whilst not something I have used as extensively as I might like, every time I look at the library I am often inspired to improve our code base. This has also enabled us to give engineers even more freedom to choose new areas of the code base to work on.
  • Lots more than I can remember, I think at this point I’ve probably started to take some of the positives for granted.

Other takeaways

Let’s face it, like many other things in life, if tech is hard to pick up or hard to get started, it’s that much harder to get excited about. One of the best things I found about Gatsby, especially at an early stage, was just how easy it was to fire up a new application and be building fun stuff in minutes. As it should be.

Too on the nose?

Tom Parsons is a Front End Tech Lead at Funding Options, and had been developing and managing Front End applications for over a decade.

GitHub
LinkedIn
More Medium articles
Funding Options is hiring

The Startup

Get smarter at building your thing. Join The Startup’s +725K followers.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store