It's day three of our four-part series of posts about running Static Site Generators (SSGs) and alternative Content Management Systems on Platform.sh. Today, we're looking at GatsbyJS, an SSG publishing framework built on top of React Facebook's Javascript library. What makes Gatsby unique and interesting is that it's written as a Progressive Web App (PWA).
Gatsby and other PWAs use a combination of client-side (Javascript) and server-side components, which can be both static assets and dynamic APIs. This gets to our third, three-letter-acronym: JAM or JAMstack—an architecture built on client-side Javascript, APIs, and Markup, as opposed to the LAMP (Linux, Apache, MySQL, PHP) server-side stack we know so well from Drupal, WordPress, and so on.
While Gatsby uses a different language (Javascript) and server-side framework (Node) than the other SSGs we're demonstrating, setting it up on Platform.sh is very similar to how we ran Hugo, the Go-based SSG.
Let's run GatsbyJS on Platform.sh
We'll start as we have before with a local version of our application. Since we're starting from scratch, we need a few prerequisites installed on our machine. If you have an existing Gatsby app, you can skip ahead. You can also download a ready-to-run copy of a Gatsby project for Platform.sh, if that's more your speed.
1. Set up your local machine
You'll need four tools to deploy your Gatsby site on Platform.sh:
- Git: install git if it's not already on your machine
- Node 8+: install node
- npx:
sudo npm install -g npx
- Optional (but really, you should): the platform.sh cli tool
For each of these tools, please refer to their own install pages.
2. Bootstrap your GatsbyJS project
You need to create a new GatsbyJS folder from a template:
You can now run the local development server:
Browse http://localhost:8000/ to check that everything is working as expected.
The npx
template already creates a basic Git repository:
Create a Platform.sh project by signing to a trial account or log in to your account.
Select a Standard
project, then choose the region you want your project to be hosted in.
Review and validate. You can now access your newly provisioned project. On the wizard, click Git remote
and copy it.
Add the remote to your local project:
Don't push anything for now. You still need to add the Platform.sh configuration.
4. Set up the
Platform.sh relies on yaml
configurations to configure the different containers to deploy. Create the .platform.app.yaml
file at the root of your project, and add the following code:
The web
section is nearly identical to the Hugo version. Really, serving any static site on Platform.sh is the same at runtime. The build hook is a bit simpler in this case as it need only run npm run build
to compile Gatsby.
Because the container type
is NodeJS, and the build flavor is left at the default, Platform.sh will automatically run npm install
before the build hook automatically to ensure all dependencies are available.
We need also two other files: routes.yaml
and services.yaml
. services.yaml
is used to configure additional services like databases, so we don't need it for that project. Just create the file:
Add routes.yaml
in the .platform
folder, and add the following configuration:
This file tells the Platform.sh router to direct all incoming requests to our gatsbyjs
container. Commit these new files:
5. Test and deploy
You're now ready to deploy the project on Platform.sh. Push the repository to the new remote:
Platform.sh will then build and deploy your Gatsby application, with the following output:
Validating submodules
Validating configuration files
Building application 'gatsbyjs' (runtime type: nodejs:8.9, tree: fafb3d4)
Generating runtime configuration.
Let's review the output of your push
. After a basic Git push output, Platform.sh kicks in and runs the build script. Under where it says Executing build hook
you can see it downloading npm packages and then running Gatsby.
(It's not as fast as Hugo, but still decently fast.)
Platform.sh then checks that everything seems correct and deploys the container to a host. Again, it generates Let's Encrypt TLS certificates for every route automatically and ends with the URLs of the application:
The last output is your application's new URL. You can also check that the project has been successfully deployed on the web interface. If you've got the Platform.sh CLI installed, jumping to the web interface from your project is simple; no need to remember project IDs, just type platform web
.
Now your basic GatsbyJS site is up and running!
As a side note, we've been focused this week on showing how you can run alternate frameworks and a variety of languages on Platform.sh. Did you know that you can run multiple applications inside the same project? This multi-app setup is a subject for another post, however it's worth noting that combining purpose-built services, like a site built with an SSG, with a blog powered by WordPress, or a headless e-commerce back end powered by Magento or Drupal Commerce, is quite straightforward. Gatsby makes it especially easy, since it's client-side framework was designed to consume APIs directly.
Tomorrow, we'll take a look at our final SSG, and the most popular, Jekyll a SSG written in Ruby.
Read the series: Four days, four languages, four frameworks
- Day 1, Java: Running Brightspot CMS on Platform.sh
- Day 2, Go: Hugo, a fast static site generator