I’ve been a longtime fan of Gatsby. About a year ago I joined a team that deploys Gatsby-based sites to Kubernetes. Since then, I’ve been chasing after the best (and maybe cheapest) way to implement incremental builds in a production environment. You might think of it as a self-hosted alternative to the major providers like Gatsby Cloud, Netlify, Vercel, etc.
What is an incremental build?
An incremental build is a build of Gatsby that generates only the subset of HTML files that needed to be updated based on the changes made to the site. Changes to page templates, page queries, static queries, and frontend source code cause HTML files to be marked for regeneration.
Basically, your CMS sends a POST call to a given web-hook when things change and triggers a build on the infrastructure/backend side. The challenge is - build infrastructure isn’t easily available in OSS. It’s unclear* how the major providers manage the web-hooks and build Gatsby sites. It’s especially interesting when you get to providers like Gatsby Cloud who claim to rebuild (incrementally) at numbers like 1-5 seconds.
*Netlify is a huge exception in that, a lot of their infrastructure is surprisingly available on GitHub
Why is this important?
There are several reasons why implementing incremental builds in a production environment is important for Gatsby-based sites.
First, incremental builds can significantly improve the performance and scalability of your site. By only regenerating the HTML files that have been changed, you can reduce the time and resources required for each build.
Second, incremental builds can also help you save money by reducing the cost of hosting and deploying your site. By making your builds more efficient, you can reduce the number of resources and infrastructure needed to support your site, which can save you money on hosting fees and other costs.
In summary, implementing incremental builds in a production environment is an important step for any Gatsby-based site, and can provide significant benefits in terms of performance, scalability, cost savings, and user experience.
Writing the Webhook
Â