A Look Back at a First Year of Using Gatsby JS.
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…
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
Contentful GraphQL Plugin + createPages + Templates.
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.
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
Like all frameworks there are small things that are easy enough to work around. But, there’s one problem that has taken more work around than I would consider ideal.
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:
What we have:
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
But that’s about it for the major negatives — and there are straight forward enough fixes for the most part, any are outweighed by the positives. Here are some more of the upvoted…
- 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
As Front End development improves at an impressive pace, frameworks and foundations for building professional applications are improving no end. Utilising these progressive tools has enabled us to improve the quality, reliability and scalability of our applications, something that is a top priority for me. Of course making the right choice at the right time is difficult, like many of you, I know wayyy too much about some Front End tech that we thought would be the way forward only for it not to work out like that (I’m looking at you relay!). But Gatsby has felt like a solid investment so far.
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.
Tom Parsons is a Front End Tech Lead at Funding Options, and had been developing and managing Front End applications for over a decade.
