So, Why Gatsby?
19 April 2019
This site, as it says in the footer, is built with Gatsby. I’ve previously had years of experience with a number of content management systems; Wordpress, Ghost, Tumblr, and phpBB among them. When I decided that I wanted to start blogging again in earnest, I spent a couple weeks deliberating over how I’d blog. I could easily have done something via Wordpress.com, or Tumblr. I was keen to host my own content, though. Tumblr’s ham-fisted pornography takedown made me skittish about putting all my eggs in a basket someone else owns. Sure, I’m not gonna start posting anything lewd here at any point, but the principle of the thing is important to me.
All the previous times I’d hosted my own blog or similar site, I got bogged down in the management of the various parts that make it go. A Wordpress or Ghost site is actually three separate services running in concert: a webserver like Apache httpd or nginx, the CMS code itself, and a database of some kind (usually MySQL or PostgreSQL) that stores all the actual content in a logical way. Keeping all those parts running healthily can be a chore, and eventually with enough posts or enough traffic such a site needs some optimization to run well. Anyone who has run a database-backed site for long enough can attest that things can quickly grow beyond a simple “one webserver, one database” setup…
And for a blog, do I really need all that technological frippery?
Nah. It’s all just text, with the occasional image embedded in it. Storing it in a SQL database server incurs a silly amount of overhead for this kind of content. So I started thinking: “What if I just start writing the site by hand, like in the old days of 1998?”
“Hell no,” I answered myself. “You don’t want that kind of headache either!”
A Middle Way
There had to be some kind of middle-ground, though. I searched for a solution that would spare me the tech overhead of a full CMS but would also abstract away the tedium of editing raw HTML for each post. That’s when I came across static site generators, which seem to have popped up as a popular thing in the last five years or so while I’ve been quite firmly in back-end software development professionally. These applications take data from one or more sources (a database, if you have one; a remote API; flat files stored on a filesystem, etc.) and build the entirety of your site into a set of static files.
Consider all the possible pages on a typical blog. There’s a home page with a paginated list of, say, three recent posts. There are all the further paginations of that list, going back to the first post. There’s a page for every post. There’s probably an “about” page. There might be tags to help categorize posts, so there’d be a page for each tag so you can easily navigate to posts on the same topic.
In a database-driven CMS, all of those things would be “built” on the fly. Your browser would request
https://example.com/blog/tags/widgeco-widgets, and the CMS code would query the database, wait for the response, and build the whole “widgeco widgets” tag page in realtime before sending the resulting HTML payload down the wire (or over the air) to your device. If five people requested that page one-after-another, the database and CMS would have to do that work for each request, whether it’d changed between those requests or not.
A static site generator takes all the data as it exists right now and generates everything. The entire possible website. The database (or other data source) does this big chunk of work once. Then you copy the resulting files to your webserver, and the data source can be turned off, if you see fit. When you make changes, you run the generator again and redeploy.
A static site generator might not be best for something in which a running database is essential, like e-commerce, but this kind of workflow is perfect for a blog. Changes are infrequent (at least on my blog; YMMV). There are also gains to be had in terms of performance and user experience. Recall from above all the things a typical CMS has to do on each request. When a website doesn’t have to do all that work, when it’s already done, page loads are fast. Like, hilariously fast. The valthonis.net homepage loads consistently in 1.17s according to WebPageTest. Compare this to the website for my podcast, which runs on Ghost and loads on average in 3.33s; not bad by any stretch, but noticeably slower and highly inconsistent based on the amount of load on the database behind it.
The Great Gatsby
Gatsby is built on top of a bunch of Internet technologies that I’ve been enthusiastic about learning for a long while, but couldn’t find an excuse to use in my everyday job. First among these is Facebook’s React, a popular library for building user interfaces. I’d done a bunch of reading about React, and it interested me greatly. The last time I spent any time seriously building web interfaces, PHP was the lingua franca for building sites, Python and Ruby were popping up on my radar, and Node didn’t yet exist. The idea of a component-based library that made building UI and managing updates based on data changes seemed awesome. Gatsby also uses GraphQL, a fascinating alternative to REST APIs that regards all data as a connected graph instead of a collection of separate resources.
It also has a pretty mature ecosystem of plugins and starter kits that make jumping into Gatsby pretty straightforward, whether you’re migrating from an existing site or starting something from scratch like I did here.
Start As You Mean To Go On
Four posts and a few weeks into this experience, I am very much enjoying using Gatsby to run this site. I’m learning a ton about modern web technologies that I wouldn’t touch otherwise. My site loads fast all the time and not just when no one is using it. My eggs are all in my basket and not subject to the tomfoolery of a service like Tumblr or Facebook. Keep eyes on this space for more updates; not just more posts, but more experiments with site design and layout as I get more comfortable being a hobbyist web developer again!
Got thoughts? Hit me up on Twitter!