Something like a blog is generally fairly static unless new a post is added, so it seemed overkill to involve a CMS like Wordpress or Drupal. Not to mention all the security updates I’d be responsible for, or paying another company to manage them for me. With that in mind a static site generator seemed like the best choice.
As many projects I work with currently involve using React, I thought appropriate to use something like GatsbyJS to make a static site. This would also give me potential skills at work for future projects.
I’ve previously used Jekyll to generate static sites, but with it being Ruby I felt out of my element, and I’m not really interested in learning it right now. It also felt like a lot of overhead to get a site up and running. I opted to try something else this time.
I wasn’t interested in coding up something from scratch, and it just so happens that GatsbyJS provides a wealth of starter-kits to work with. I didn’t want to code from scratch as I felt I wouldn’t learn a lot from creating my own application - I have a general idea of how things should work in React, so I’d rather take a look at something already done and tweak it to my needs. I wouldn’t be providing any value to the open-source community either as there are probably plenty of “React blogs” out there already.
After seeing Dan Abramov’s Overreacted blog was powered by the
gatsby-starter-blog starter I decided to take a look myself. It had everything I needed - static site generation, lightning fast performance, out-of-the-box RSS, and a pretty good looking theme. After poking around in the repo a bit I figured this was just what I needed.
Besides a few theme bits here and there (read: splash of teal everywhere), I didn’t change much. I originally omitted the
<Bio /> component from all pages as I didn’t have much to write there, but later added it back in with a link to a Contact page.
Speaking of which, I also added a custom Contact page. This by itself doesn’t do anything, but thanks to my webhost it acts as a contact form and accepts submissions (more on that later). GatsbyJS itself doesn’t do anything besides provide a static page.
I used Git primarily because I am familiar and comfortable with it. That’s the long and the short of it. Version control is essential, even for personal projects. If you’re not already I’d recommend you get familiar with Git, or at least another alternative. Know how to make branches, revert commits, stash code, and don’t be afraid of
git rebase! Git has some of the best documentation around.
I used GitHub as a code repository again because I was most comfortable with it and familiar. I have found it reliable for my use cases, and is generally working when I need it (GitHub does go down sometimes…). There is also a large open-source community there, so it seemed prudent to have my open-source code hosted there.
This was the piece I struggled with the most. I originally wanted to self-host my site, but that proved to be too tedious for me. I’d rather have everything “just work” rather than be in charge of deployments or security patches. That would also mean I’d have to be in charge of a server and keep on top of it. No thanks.
A friend of mine offered me some space on his server which was very kind of him, and it would’ve worked fine since this was a static site. This didn’t work for me though since it’d require manual deployments. It’s a small thing but I don’t want to be responsible for managing them. Next!
GitHub Pages seemed like the choice for me. It deployed automatically based on the repo contents, and doesn’t require any maintenance. This would be on GitHub’s servers, so no security patches. They support custom domains (and with HTTPS). Win win! This worked fine in the beginning, but I noticed something I didn’t care for - if I wanted to update my site it required access to my own development machine. Since I chose GatsbyJS which uses React, the static version of the site needs to be transpiled and built - which requires the code repo cloned and set up. Yuck! That’s too much work.
What I wanted was something that could handle automatic deployments by building the site on their servers, and provide hosting. Enter Netlify!
It offered all of the same features as GitH
ub Pages, but also allowed for building the site on their servers. It monitors the
master branch (by default), and re-builds the site when it detects changes. This was perfect! Now I could make updates from anywhere and commit them to my repo. Netlify would then deploy the site for me and that’s it! Perfect.
As an additional bonus (I was not aware of it when I chose Netlify) - they offer form handling! This means I can accept form submissions from visitors should I so choose. I decided to throw together a quick form for contacting me if anyone desires. It can even forward submissions to your inbox. Very handy!
Something like Cloudflare probably seems overkill for a blog (let alone a static site), but I thought why not and give it a shot. They’ve recently impressed me with their 188.8.131.52 DNS, and they regularly post about goings-on and act very transparently. I personally value that a lot, and as such I’d like to use their services. Out-of-the-box Cloudflare’s DNS services provide lightning-fast resolution time - so my already snappy blog should feel even snappier (Safari users especially - just kidding). Cloudflare also caches my site, so should Netlify go down - Cloudflare can serve a cached version of my site. Since my site is generally pretty static, this is ideal! There’s also things like DDoS protection, load balancing, and other fancy tech that my blog (probably) won’t need.
For my domain names I use Namecheap. No real reason beyond good prices. They offer lots of configuration options for your domain, although this is likely standard across any domain name provider.