The maintenance nightmare of my previous headless drupal + Angular JS prompted me to move to something radically simpler.
Once again I find myself between life chapters with a few weeks of downtime to sharpen the saw. Along researching some new industry options (cannabis and dolls both looking interesting) and business idea brainstorming with my old business partner Ben, I found time to give my website an overhaul. I’ll post more on the chapter changing later, for now lets look at the web bit.
Previously on neilcameron.me Almost exactly three years ago, I consciously took the decision to over engineer neilcameron.me to trial an emerging build pattern of decoupled Drupal as CMS and a JS web app as the frontend. Drupal 8 was in beta and Angular was in vogue, so it seemed like a natural pairing.
after spending half an hour faffing around with Gulp and Bower (remember them?) I couldn’t even get the Angular site to build
The main problem came about 2.5 years later when I wanted to make some changes. Turns out after spending half an hour faffing around with Gulp and Bower (remember them?) I couldn’t even get the Angular site to build locally. Likewise, the backend CMS started out on Drupal 8.0.0-beta11while the most recent version (after a couple of drupalgeddons) is 8.5.4.
The Next Generation I knew I needed a low maintenance, easy-to-update platform for my new site. For the Twivel TV website I’d used Jekyll hosted on AWS S3 (via s3_website). I was really happy with the result and decided to take a similar approach.
A statically generated site is a collection of templates, content pages in markdown format and other structured content which can be compiled into a series of HTML files which are served to the reader. Traditionally CMSs have a DB for storing content and the HTML pages are generated on the fly by a scripting language like PHP. This can lead to poor performance due to DB reads which then requires some sort of caching strategy, while simultaneously providing a large surface area for potential malicious attacks.
After a bit of googling it seemed like Hugo is the current preferred choice for running a static site. I gave it a try and it’s dead easy to get up and running. The documentation is generally pretty good, although there are some concepts like leaf and branch page bundles or page resources that could do with some better explaining.
For hosting I considered a DIY S3 + Cloudfront setup but when I saw the Netlify offering it was a no brainer to user that. S3_website makes things simple, but you still need to think about invalidating caches, creating a mini build script and running the command each time to deploy. Netlify abstracts all that away and provides a sort of CD service that connects straight to Github.
Takeaways I always like to use my personal site as a guinea pig to try new things. In this case I think there are few lessons learned that can be applied more broadly to organisations considering their web presence:
- A high maintenance tech stack not only requires an ongoing commitment but can also pass a tipping point of not being maintained which then blocks further development without a significant investment of time.
- Bleeding edge frameworks that require diverse tooling (I was using bower, gulp, ng-factory and undertaker just to get started) can potentially lead to a higher maintenance and brittle build process. This is becoming one of the strongest selling points of boring, mature frameworks like Rails.
- Tools like Forestry (a cloud CMS for static sites) and Netlify are beginning to make statically generated websites realistic options for organisations with lots of content but not much interactivity. There are great benefits to be had around the reduced surface area for attacks and the ease of high performance hosting.