If you’re a Gatsby open source enthusiast you’re probably aware of Gatsby Cloud. But W.T.Flip actually is Gatsby Cloud, and why would you choose to make it part of your workflow?
Let’s say that, like me, you have a blog. And when working on this blog, each and every time you make changes (be it changes to the code or changes to the content) you push those changes to a remote repository while your hosting provider takes care of the rest. It’s a great setup — at first. However, as my blog has grown I have been noticing a steady increase in the time it takes to build.
I host my blog on Netlify and I get 300 free build minutes a month. Each time Netlify builds my site some of these free build minutes are used.
This isn’t a huge problem for me, because each build takes two or three minutes and I only update it every once in a while. But if you’re making changes more regularly, either to the code or to the content, it won’t be long before you’ve used up those free minutes. And this is where things can become expensive.
There are many benefits to Server Side Rendering (SSR) — inherently secure sites with super speedy load times and built-in SEO. What’s not to like, amirite? The only real drawback is the “time to build” issue, which for a long time has made SSR basically off the menu for very large sites or those with constant changes and updates. It’s precisely here where Gatsby Cloud can help, though.
Gatsby invented the first-ever widely applicable, frame-work based incremental builds to solve this very problem. Meaning that only Gatsby Cloud can re-build the parts of your Gatsby site that have changed since it was last updated — meaning you’ll significantly reduce “time to build,” which in turn reduces hosting costs.
This is a little difficult to grasp at first so I came up two fictional scenarios which might help better illustrate the problem.
The Analogy
Scenario A
You’ve popped out to buy some milk and on the way home you bump into a friend. You might say “Hi friend, what have you been up to?”, your friend responds by explaining everything that has even happened in their life from the moment they were born right up until the moment where you said “Hi friend…”. This process was so lengthy your milk has soured and you’re left questioning why you are even friends with this person. You return home thinking, What a bad friend.
Scenario B
You’ve popped out to buy some milk and on the way home you bump into a friend. You might say, “Hi friend, what have you been up to?”. Your friend responds by explaining only the things that have happened between the last time they saw you right up to the moment where you said “Hi friend…”. The duration of this conversation was a fleeting moment in time, your milk is still chilled and you return home thinking, What a good friend.
In the world of SSR, Gatsby Cloud is your good friend!
Below is a simple yet typical workflow showing where Gatsby Cloud fits into the mix. Sticking with our analogy, iteration A being “the bad friend” and iteration B “the good friend” scenarios.
Workflow A (bad friend)
In this scenario developers change site data and push to a remote repository, and/or make CMS content edits or additions. This in turn notifies Netlify, which re-builds everything before the static files are deployed and the website updates…eventually. Because that is just how standard static site builds work.
Workflow B (good friend)
In this scenario developers change site data and push to a remote repository, and/or make CMS content edits or additions. This in turn notifies Gatsby Cloud which re-builds only the bits that have changed before pushing the static files on to Netlify to deploy and the website updates…more or less immediately.
As mentioned, I get 300 free minutes of Netlify build time each month. Workflow B’s “good friend” scenario means I’d use exactly 0 of those build minutes because Gatsby Cloud is doing the lions share of the work. Netlify is now only used to host the site.
Gatsby Cloud naturally comes at a cost (there is a free tier for personal projects, thought it does not provide access to the Incremental Builds feature). However, given its main selling point is to reduce “time to build” I do believe the recurring cost comparison will be much more favorable, especially when we start talking about larger enterprise sites.
In addition to Incremental Builds, Gatsby Cloud has just introduced another fun new feature: “multi-site” builds. This is a smart way for Gatsby Cloud to take responsibility for multiple sites all from the same repo. (If you’re not familiar with the concept of monorepos here’s a good article by Yarn: Workspaces in Yarn).
To help demonstrate this a little better I’ve created a fictional company with a fictional, but potentially very common and very real, set of business requirements. Let’s look at how Gatsby Cloud can fit in with my business model.
The Demo
Apple Store is an e-commerce platform where customers can buy, well, apples. Apple Store is international and so requires both a US Store and a UK Store.
Each store is powered by its own Shopify storefront. From here my team of ace apple merchants independently update their respective storefronts to promote and sell apples on both sides of the Atlantic. Our products change regularly and, in fact, items go in and out of stock many times a day. Thus it’s important our sites reflect the current stock levels in almost real time.
Here are some preview links…
…And here’s the code repository:
You’ll notice it’s a monorepo which, among other advantages, allows me to manage the code, styles and brand identity for both Stores and the Style Guide all from the same place.
Let’s quickly walk through this setup before elaborating on how I’ve used Gatsby Cloud to manage the builds and deployment of many different sites all from the one monorepo.
The Themes
Both the Stores and the Style Guide are styled by a Gatsby Theme, this can be located in the repo in apple-store-theme. The Theme is underpinned by Theme UI, a library for creating themeable user interfaces (which, if you haven’t used before you really should because it’s super brill brills). This Theme is responsible for how things look. Theme UI ships with a number of UI components built in, and these pretty much allow you to create any UI elements required. The Style Guide simply renders all the Theme UI components on one page, along with presenting styles for Markdown should you wish to use it.
The Stores also use another Theme, apple-store-core. This Theme is responsible for composing the styled Theme UI components to make the features used in the Stores and utilizes the gatsby-source-shopify plugin to fetch data from each of the Shopify storefront APIs at build time.
As mentioned above, both the Stores, the Style Guide and the two Themes all live in the one repo — but we don’t want to build and deploy all of the sub-repository in the repo. Luckily for us, Gatsby has already thought about this and we can easily let Gatsby Cloud know which of these sub-repositories it should be responsible for.
When you start with Gatsby Cloud you’ll be met with the familiar “Add a site” button. Click it to get started.
You’ll be prompted to select the main repository from your GitHub account. The next step is now to select which “base directory” you want Gatsby Cloud to build from:
If you repeat this step for each of the sub-repositories in your monorepo you want Gatsby Cloud to build you’ll have a cheeky looking setup up like this:
With the sub-repositories or “base directories” configured Gatsby Cloud will re-build whenever a push is detected from GitHub.
But wait there’s more.
Since both the Stores are powered by Shopify we’ll also need to let Gatsby Cloud know that re-builds are required as and when a change occurs in the Stores’ Shopfiy storefront accounts. This can be achieved using a webhook:
In both cases when code is pushed by a developer to GitHub or when anything in the Shopify storefront account changes, e.g a product is added, removed or when a quantity or price changes, Gatsby Cloud will only re-build the site effected by the change and will only re-build the parts of that site effected by the change. Blazing fast indeed!
I’ve been developing Apple Store for the last two weeks and during development I’ve noticed a big difference in the “time to build”, in some cases I’m seeing the store update in less than 20 seconds… which is mind blowing!
Naturally I don’t know about every possible business model and it’s requirements but it’s a fair assumption that web hooks and regular re-builds are required for all manner of business and if you’re looking to create blazing fast sites using SSR, Gatsby Cloud is the perfect accompaniment.
And that’s it, see ya friends ✌️