The Great (and not so great) Gatsbyjs

Richard Moss
Aug 31, 2018 · 7 min read
“So we beat on, boats against the current, borne back ceaselessly into the past.”
F. Scott Fitzgerald, The Great Gatsby

Gatsbyjs is a great addition in the toolkit of React developers. Like every tool though, knowing when to reach for it is key. At LeanJS we’ve now used Gatsby on 3 projects since Jan 2018, two of which are currently in production and one that we had to shift over. We’d like to share our experiences and conclusions :-)

The Challenge

In early Jan we had a project where we needed to migrate a literary site from it’s original flat file system to have a custom UI to deliver a user experience that matched it’s prestige. We were passed a Wordpress instance with all the data which had been ported over 😐. Our standard stack is React with SSR, GraphQL and serverless back-end. Luckily, as graphQL is awesome you can simply wrap and existing restAPI (like wordpress has) and consume it via graphQL, an approach we’ve taken before, so we were confident in taking this approach.

Using Gatsby with a big data set (v1)

As Gatsby was just starting to come on the scene, we spun up a quick prototype using the gatsby-source-wordpress plugin to see if it was a viable option. In our case we had ~9000 bits of content (posts) which was admittedly ambitious given that it’d been tested with 900. But hey presto it worked! So all the Gatsby goodness such as out of the box code splitting and lightning fast navigation between pages looked like it was in the bag. The build time was at about 5 minutes which seemed reasonable for a mostly static site which would not have to be re-built more than a couple of times per-week.

Having carried out a user research phase, we ran an initial rapid prototyping phase using SemanticUI react component libary to build a clickable prototype. Up to this point everything was working well minus a couple of build errors from time to time.

The big issues

For those who have been working with Gatsby a bit, you’ll have noticed there is a big difference between when you are running something in “develop” and wether that works when you run a build. Put simply, just because you can run something locally using “gatsby develop”, that doesn’t mean it will build with no errors. Of course the solution to this is to run the build regularly and then use a basic local server to check everything.

Solving errors that occur during the build is not ideal, as if your team is making a lot of changes quickly and runs the build only a couple of times a week, it’s possible you have multiple errors to solve and you’ll need to re-build every time to see the error. When your build time is 5 minuets this is a minor annoyance, but what happened next was a bit more dramatic…

When you start to put in a lot of styling (via styled components) and use other open source library’s to add functionality, the build time will start to increase dramatically. In our case it went got up to about 25 minutes. At this stage it’s no longer viable to keep running builds all the time and solving the errors becomes increasingly difficult. The second big problem is that due to the way the static build works, everything is stored in memory during the build so you need to have a large capacity of RAM to handle it. After a certain point (after more libs were added) everyones computer was running out of memory when trying to build the site.

RangeError: Maximum call stack size exceeded

This is now a fairly well known issue and you can read more on it in this thread. To save you some reading though, the answer is that it’s solved in V2 (still in Beta currently) as they are no longer using the same webpack static build process that was causing the issue.

Back in January however V2 was not really on the horizon and we needed to deliver on a tight timeline. What we did was take the decision to move the whole gatsby site over to a standard create-react-app with server-side rendering and use GraphQL to consume the wp data via wp-graphql.

This was not the easiest thing to do, but in the end we got it over onto our standard stack in about 4 days 😅.

The lesson learned

The key learning from this experience was that when using a new tool, you need to be prepared and able to quickly adapt to your “default” stack.

The React ecosystem is awesome and is very un-opinionated. This is great but it means that we need to be more prepared to make decisions as engineers and fully understand all the technologies that are working in conjunction. When you’re on a tight deadline, it’s easy to fall into the trap of wanting to go down the framework route, where convention over configuration will help you get the job done faster. However, when the flint strikes the metal, you need to be confident that you can make a rapid change and go more vanilla. While Gatsby is a great tool, there is no doubt that it is more opinionated, with all of the advantages (and disadvantages) that come along with that.

Our prototype homepage for the Agni Magazine

Opinionated vs Vanilla

You may have been thinking that the conclusion is to just always go as vanilla as possible. Modern software engineering must be more nuanced though if you want to achieve a good balance in speed and quality. At ReactJS Academy we are always pushing the point that you must be a good JavaScript dev if you want to be a good React dev. As Kyle Simpson once said to students at one of our bootcamps:

“You should aim to be an expert in your layer of the stack, and have a very good working knowledge of the level below.”

For us that means being expert in the React ecosystem and very high level at vanilla JS. Failing this, you can’t expect to fix things quickly when they go wrong, which ultimately could lead to a negative experience for everyone concerned. This was again highlighted during the switch over, without knowing how to implement SRR in React, we would have either continued to struggle on or delivered an inferior result. You can read up on how to do SSR in React with concise instructions here: https://github.com/leanjscom/fb-messenger/tree/SSR-part1#reactjs-facebook-messenger

So when and where do we use Gatsby?

Having this experience with Gatsby on a project was not something that put us off, if anything the opposite. The benefits are pretty clear. If you are a team that is well versed in rapidly building apps with React’s component based architecture, when faced with a content heavy static site, Gatsby is a great option. So when we decided it was time to re-vamp ReactJS Academy and LeanJS websites (previously Jekyll), we knew where to turn. In both cases the sites are not complex, but by building with Gatsby we can integrate all our React experience and workflows in order to rapidly build and test the sites. When there is no big data set or tricky integration via a plugin, for React developers who want to build a presentational site such as a blog or CV, Gatsby is a great option.

Conclusion

Pick the right tool for the job. If you’re building a basic static site and you know and love React, Gatsby is my recommendation. But take the time to discuss it with your team, make sure you can also convince others of the benefits before charging ahead. If you are building a complex web app, the answer is more mixed, but think carefully about the tool you pick and wether it is appropriate. Not planning is planning for failure, so whatever you choose you need to be both confident with the underlying technology and have a contingency plan 😉.

Let us know your experiences with Gatsby and other tools in the React ecosystem in the comments 😎

LeanJS

React, GraphQL, UX, Lean news and opinion

Richard Moss

Written by

LeanJS

LeanJS

React, GraphQL, UX, Lean news and opinion

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade