“Back in the day”, we used to handcraft our websites with static HTML files on our local machines before uploading them somewhere; either a free web host like Tripod, Angelfire and GeoCities, or a paid one like GoDaddy. The more initiated might have used SSI and—from my perspective at the time—the “crazy ones” used Perl through CGI. Then, as things modernized, PHP took over and soon every website had swappable themes. WordPress improved much of those conventions, Ruby On Rails was an unsanitized/insecure—but very automated—mess, and our websites were very much tied to a webserver. Fortunately, all of that is the past.
While most websites have truly become software, it’s still possible for them to be simple enough to run on little more than a file server. Static site generators are not a new thing, but their modernizations make them better than ever and they take us back to some of the old DIY days of website creation. Local tools with no extra baggage.
I chose to rewrite my website using 11ty (Eleventy), a modern clone of Jekyll. My blog posts are written in Markdown, letting me focus on the content. The templates and more customized pages are written in Nunjucks (and HTML & SCSS); but I’ll later refactor to JSX when it supports “front matter” (the header metadata for each page). Publishing articles and site changes is handled in the cloud through CI/CD with GitHub Actions, but the actual authoring and development is still performed with local files on a workstation.
It was time for me to upgrade from my old shared web host to something better. While I could’ve opted for an affordable VPS, my choice to implement a distributed design on AWS has provided much better—and infinitely-scaling—performance and with an even lower annual cost.
git push’ing my changes.
And because AWS API Gateway supports OpenAPI, I didn’t even have to write a RESTful API implementation—which would’ve otherwise been with Express 5. Per my specification, requests are simply routed from DNS, to the gateway, then to my AWS Lambdas (cloud functions).
The code was written to be as agnostic as possible; meaning that if for whatever reason I felt it necessary to migrate from Amazon to something else—such as Google or Azure—it wouldn’t be much effort beyond changes to dependencies and maybe I/O.