This article was written on December 14, 2018 with the most current Gatsby version being 2.0.7.
2018: The Year of Gatsby
Changes in V2
Here is a quick glance at some of the improvements added in v2:
- webpack 4
- React 16
- Babel 7
- GraphQL schema stitching
- Reach Router
- Gatsby themes
- Static queries, no more layouts, tracing and more!
How Gatsby v2 Has Benefited Us
What main benefits did we at Mediacurrent gain from these changes? Performance and flexibility. When building enterprise level experiences, we need those two things in abundance. In the past, Gatsby was perceived as being only for ‘small’ projects or ‘sites’ instead of ‘apps’, but v2 should put those concerns to rest. We’ve been working to utilize Gatsby at our large scale, and here’s how those v2 changes have made that possible.
Performance: Gains for the User, the Client, and Developers
With increased speed inside and out, and a boost of accessibility, Gatsby v2 took its main strength, performance, and somehow made it even stronger. Here’s how Gatsby’s improvements in performance are a triple benefit, for users, for our clients, and for developers.
With the introduction of webpack 4, React 16, and Babel 7, Gatsby now does even more optimizations under the hood. The stats are pretty amazing: the overall client side bundle shrank by 31%. Updated webpack and Babel mean the code you write is going to be more performant as well because of an improved code-spitting algorithm, faster transpiling, and better lazy loading of assets. The benefit for the user is obvious (they see the page faster!), but what about why this benefits client? The benefits of a performant site often show up on the balance sheet. See this case study showing a massive 60% increase in lead generation by Youfit. Lastly, the benefit for developers is apparent if you have ever maintained a company wide webpack config (or several!). If you have, you know how many hours can be spent trying to optimize each project or fix webpack plugins needed in one project but not another. Gatsby’s exceptional out of the box handling of tooling saves us dev hours.
Accessibility With Reach Router
Beyond speed, accessibility and usability are another metric we used to gauge site performance. React apps can feel more difficult to make accessible, so we were very glad to see Gatsby adopt Reach Router. This is essentially a drop-in replacement for react-router, but with an emphasis on accessible navigation. Accessibility is very important to us, and having a tool that shares that emphasis is reassuring. Also, again, having Gatsby utilize this saves us dev time and delivers a top-notch experience. (Not to mention this change contributed to the lower bundle size mentioned above 😏).
Overall, performance gains in v2 have saved us time and helped us deliver some of the most comprehensively performant sites in our portfolio.
Flexibility: We’re (not) Gonna Need a Bigger Boat
Flexibility, or ability to scale, has been a huge win in Gatsby v2. As I mentioned earlier, there’s a misconception that Gatsby is only useful for small-scale static sites (blogs, documentation, etc). With v2, that idea has made that obsolete, and we have been using it to build large-scale dynamic apps.
Under the Hood
Those updates of webpack and Babel that helped with performance on the client side, have also made drastic improvements in Gatsby’s ability to scale up. There were also some internal PRs that improved build time memory usage and allow for larger builds. We have 10K page projects with build times around 90 seconds. We’ve also found that this number does not increase in direct correlation to page number due to the base build operation time, so going to 20K pages does not mean double that build time.
This flexibility is important to us because we can use Gatsby to move quickly on smaller projects, but we are also able to follow the same workflow and scale it up for our larger ones. Before v2, Gatsby was not able to handle sites far above 10K pages.
GraphQL Schema Stitching
Another amazing improvement for flexibility is the introduction of gatsby-source-graphql. This allows the consumption of any third-party GraphQL APIs in a far easier manner than before using GraphQL schema stitching. For large and enterprise level CMS users, try exposing your CMS’s GraphQL API instead of the JSON API and Gatsby will be able to consume it with less parsing. It will then stitch it together with your other data sources to form the whole internal GraphQL server. We are excited to integrate this plugin more and more with our process.
Last, but not least for flexibility is the creation of Gatsby themes. For a glance at themes, this talk by Chris Biscardi is the best source of info to date. Gatsby was already flexible from project to project using starters, but themes take that to another level by letting a project read from an upstream Gatsby config and stay up to date, but override where needed. Still an experimental feature, this is a big step towards even more control like subtheming, that we are eager to see more of in future updates.
At the beginning of 2018, Gatsby may have been on your radar, but going in to 2019, its growing community and fantastic v2 major release have made it one of our favorite tools here at Mediacurrent. The increases in performance and flexibility make it a fit for a very wide range of projects, not just small or simple. We look forward to helping it continue to grow and evolve. If you have any questions or comments feel free to reach out or leave them below!