I haven’t developed a new WordPress theme for this website (that I really loved) in a long time. So naturally, it was time to re-examine my personal tech stack. If you personally know me, you know I’m a WordPress advocate. Big fan of ol trusty.
There’s a few problems with WordPress I’ve been hung up on for a while now. It can be a bit slow (sometimes). Media managing can be painful on the front-end. Deployment processes are… all over the place. Historically, I’ve been a huge fan of Trellis from Roots. While we’re at it, I was a big fan of Bedrock too. Finally, I work with React and JavaScript all day long — why can’y my personal website run on a modern tech stack too?
Well, I came across this post from Chris Coyier, and I was pretty much sold on the JAMStack concept immediately. At work, and at other organizations like Twitter, server-rendered pages are stupid fastest. Heck, they’re typically standard these days for most web apps. Enter the Gatsby + WordPress stack. Why abandon years of publishing paradigms when you can keep them?
There’s no shortage of tutorials on the Gatsby + WordPress setup. Initially I played around with some starter projects, like this one. I personally started (and later forked) with egghead.io’s starter. It’s pretty spectacular out-of-the-box, and if you enjoy love @emotion theming or styled-components, I think you’ll dig too. But, really Gatsby itself has a lot to love. For example, Gatsby has drop-in support for server-rendering. Super cool stuff. I really enjoyed Juliano Rafael’s (@frontendwizard) notes on this subject:
Progressive image loading? Inlining of critical CSS? Painless PWA configuration? You name it, Gatsby got you. It is really impressive. Don’t believe me? I encourage you to try it out.
The solution for images is so good, that is constantly referred as a strong point of Gatsby, even thought it actually is a plugin. All you gotta do is add a couple of plugins into your Gatsby config file and you’re good to go. Your images will be available on the GraphQL API at build time and the image component will handle all the resize, picking the best file format and everything else. You even get a blur up effect to improve the user experience for free.
That’s just the tip of the iceberg. Seriously. These web apps freakin purr. I’m overdue for writing a full tutorial on this subject, so stay tuned. But, for now I want to share a high-level overview of the technical lift I undertook for my site migration.
My order of operations (yours might be slightly different):
- Duplicated my original website (legacy-site was historically hosted on DigitalOcean, so I duplicated the Droplet)
- Migrated content from legacy-site to api-site for parity
- Created a Netlify account
- Connected my Netlify site with the Gatsby-site repo (pushes/merges with master trigger deploys!)
- (API-site) Download and install the Gatsby Toolkit plugin from GitHub
- (API-site) Download and install the WP REST API Frontpage plugin from GitHub
- (API-site) Install WP-REST-API V2 Menus plugin
Now that we have our API-site prepped for deploy-hooks, exposed the frontpage and menus endpoints — we’re ready to consume the API with our server-rendered React app powered by Gatsby. Here’s a sample of my gatsby-config.js file:
...
resolve: `gatsby-source-wordpress`,
options: {
// Your API WordPress source goes here.
baseUrl: `example-api.https://stephen.news`,
protocol: `https`,
// Fetches posts, tags, categories, etc from the baseUrl.
includedRoutes: [
'**/menus',
'**/categories',
'**/frontpage',
'**/media',
'**/pages',
'**/posts',
'**/tags',
'**/users'
],
useACF: false,
},
...I absolutely love this setup.
All of the un-fun configuration stuff is already handled by the WordPress/WP REST API side, and all of the actually fun conventional interface building is done on the… well, the interface side. A complete separation of church and state, if you will. It’s a thing of beauty. Absolute zen.