For the past few years, I’ve been using Gatsby as the main tech behind several of my blogs. I love the fact that I can edit simple Markdown and my site is magically updated on the server with a fresh React-based static website. Unfortunately, as cool as the end result may be, it’s far too complex and cumbersome for the end result. What’s worse is that, even with the complex back-end tooling in place and functioning flawlessly, the act of posting new content is far more tedious than what it needs to be. The end result is fewer updates and an eventually stale and boring site.
Tedious Setup
Let us break down the tech stack allowing Gatsby to appear magical…
Git (AWS CodeCommit)
Once you have the local tooling setup for your site to build, it needs to be pushed up to a code repo. Since most of what I do online is with AWS, this means sending it to CodeCommit. From a developer’s perspective, the act of pushing it up is trivial. However, what is not trivial is the fact that you end using cracking open your IDE or a local text editor to make said edits. Even if I used Cloud9 or some type of online editor, it’s still an editor and still means working with text files that need to be pulled down, edited, and committed. And, while, yes, I could stick my public content in a public Github repo, and edit it online, I’m still editing code directly in the source repo. Trust me, after that “new code smell” wears off, this process is more than annoying. With WordPress, on the other hand, I have a myriad of options… a web-based text editor with a draft mode, the ability to send an email to WordPress and have it converted to a post, etc. Of course, all of these options are non-destructive.
CI/CD (AWS CodePipeline)
For the Gatsby content to be compiled and pushed to the public web host you need to stand up some type of CI/CD process. My choice was AWS Code Pipeline, of course. And, yeah, it’s something we regularly do as developers but… dude… this is a blog! Even if I spend an hour or two standing up a new pipeline, it’s time I don’t have to spend with a CMS engine. Oh, and let us not overlook the fact that AWS charges per pipeline so there’s an extra cost involved as well. With WordPress, your data is sitting in a database, or on the drive, and is rendered on the fly when it is viewed.
Web Host (AWS CloudFront)
Okay, I know what you’re saying. “It doesn’t matter what technology you use. You will need a host.” I’m not disputing that. And, I absolutely love AWS and CloudFront. I’ll use them forever on projects. However, the amount of work required for using CloudFront is simply not worth it for a personal blog. First, your domains need to be in Route 53. Next, you need to use Certificate Manager to request your certs for all of the names you will use on your blog. And then there is the configuration needed for CloudFront, its regions, its origin rules, etc., etc., etc. Oh, and once CloudFront is ready, you’ll need to return to Code Pipeline and Route 53 to connect all of the services. For a WordPress site you can … well … there are countless easier options. From performing a one-click deploy from AWS Marketplace, to setting up a LEMP stack on an EC2 instance, to Digital Ocean, WordPress.Com, or the other million hosts out there, almost every one of them will have you up and running in minutes without having to know anything about what’s happening under the hood.
LEMP Stack
Now, I’m not here to bash AWS or sing the praises of WordPress. This post was only ever meant to explain why the site is changing and apologize for any missing content while I swing it all over from CloudFront. However, what I would like to offer are a few links to some helpful articles that make standing up WordPress (even multiple instances on the same box) incredibly easy. I snipped these and pulled them into Evernote as soon as I found them. And, they are what I use whenever I need to stand up a simple blog in a non-critical environment: