This website

A recursive image showing this website in the spot where the header image is supposed to be

TL;DR this website = A rust static site generator + S3 + CloudFront

This website turned out to be quite the project for me, so on this page, I'll give you a bit of a behind-the-scenes.

When I began dreaming this place up, I had a few things that I wanted to keep in mind:

  • Cost. I don't have a lot of money or income right now, and I don't expect the website to get much traffic, so keeping costs down was an absolute must. 8£ a month for a traditional hosting solution might not sound that bad, except for something that I expect to be visited maybe a couple of times a month when I don't have an income it kind of is.
  • Customisability. I'm a tinkerer, and I like things to be the way I like them.
  • No ads or unwanted popups. I value experience and aesthetics and ads, and popups make that impossible. I also think good content is its marketing, so I don't think I need them.
  • Blog (optional). I've tried to keep a blog once or twice before and while I enjoyed it, and keep thinking of things I want to write about, I also really struggled to stay consistent on that front. Therefore, if it would be possible to have a blog with this website, that would be a nice bonus, but not a deal-breaker.

Backend

Given the criteria above, I decided pretty quickly that this website was going to be a static one since it is pretty much the only solution that fits the above criteria. Since I do everything locally and upload the result, I can set up whatever toolchain I want as long at it all outputs valid HTML at the end. I'll talk more about the one I picked in the next section, but suffice to say I'm thrilled with it.

Static websites are also much cheaper to maintain than traditional dynamic websites. Partly because of size, partly because they don't need any computing resources. This website is, at time of writing, around 8.3 MB, with the vast majority of that consisting of logos, pictures and other static resources like PDFs. Another point is that I only need to pay for storage instead of a whole server. All you're doing when you visit this website is requesting a file, instead of having a server do all sorts of calculations and creating the files it sends you on the fly. That also has the added benefit that the site loads fast!

It also came with a lot of other added benefits. First of all, privacy and security, mainly yours to be specific. I wanted something that would log as little as possible. There are many reasons for this. Meme of a man tapping his forehead with the caption "You can't get a data leak if you don't have any data" For example, GDPR is enforcing stricter regulations on websites, keeping logs and other data costs money, and the more moving parts you have to a website, the harder it is to make it secure. I don't want to be implicated in another security scandal, and I don't have enough working hours to monitor this space actively. But I also wanted this because I believe in only collecting what that you need. One of the oldest adages in both computer science and statistics is:

Garbage in, garbage out

This website has a very minimal amount of javascript that all runs in your browser, and at the moment, it doesn't take any input or log anything. If you do those things that give hackers more opportunity to do weird things you didn't consider, so my best defence is just not doing any of that.

That is all part of a sort of life philosophy I try to follow.

Get what you need, but not more than that

That makes things easier to maintain, (though I have been known to overengineer thing from time to time I'll admit) and is overall better for the environment. Technology is still advancing rapidly, but I don't think that the way we treat things like storage and computation is sustainable. Let us start looking at things like efficiency again instead of just raw performance.

This static website is all I need, and so I wanted to limit myself to that. That helps me maintain the darn thing, keep costs low, and make sure I don't become part of the next privacy scandal. Pretty good deal, right?

Picking a static site-generator

So now that I'd decided to use a static site generator, I had to pick one. Can't be that hard, right? Well, not exactly. I went through quite a few options. There are a lot of them out there such as Jekyll, Sphinx, Ghost, Gatsby, Hugo and Zola.

My first consideration was that I wanted a stack that I knew somewhat. I knew I was going to customise pretty much everything heavily. Therefore knew I'd already had to dive back into HTML and CSS, so I wanted to spend as little time as possible learning new languages/toolchains. That already cut out Ghost, Jekyll and Gatsby.

Secondly, I wanted something with a healthy ecosystem. Because this is just a side project, I can't spend too much time on it, so while I often don't mind taking a DIY approach to stuff, I knew that that would prove fatal for a project like this. That limited my options quite a bit since healthy ecosystems are rare, especially when you're a hipster like me.

Sphinx I already had some experience with, since that is what I'm using to document my python project PyNeg. Still, I find it very cumbersome to use, especially if customisation is involved. It's hard to get at the internals or interact with it in different ways than strictly intended, and I got put off by that prospect. Additionally, I find it relatively slow and let's be honest; I don't want to have to wait for my dopamine thank you very much.

That left me pretty much with Hugo and Zola. Hugo, I liked it. I had already used it once before to make another website. It was fast, customisable, has a healthy ecosystem with lots of themes and extensions and some excellent QoL features. Initially, I thought I'd go with that and started my work with it. I'm not super familiar with Go, but enough that I was willing to give it a try.

Overall I liked Hugo, except for one thing. The templating engine it uses drove me crazy. Mostly the inconsistent scoping and the weird prefix syntax that was applied very selectively put me off.

So I finally settled on Zola, and so far I'm pleased with it. It's written in Rust, which means that it's pretty darn fast. I've also been interested in Rust for a while now, so I figured making this in something that uses Rust might help me get into that more. What's more, the community and documentation are good enough that I find it very usable, and the templating engine is robust and consistent sufficient for my liking. So there we go, Zola, it is!

Hosing

Next was the hosting. I knew this was going to be the most significant source of cost, so I took quite a while to decide on this. I thought about self-hosting for a bit, but I eventually decided that would mean too much overhead and too little downtime. I also didn't want to go with any of the free hosting services because of my concerns mentioned above about security, privacy, ads and popups. If you put your stuff on someone else's platform that is generally very hard to control, ask any Youtuber about COPPA. I also still believe in the saying that "if you don't pay for something, you're the product".

I also wanted something away from recommendation algorithms. Just something I can point to when someone asks me about my work. I don't expect to build a following, and that is what most services are focused on.

That leads me quite quickly to cloud hosting. For this, I had three main contenders. AWS, DigitalOcean and ExoScale.

ExoScale is a relatively small (relatively mind you) Swiss competitor to AWS. The advantage of them is that they are an EU based company, meaning they are bound by EU regulations and at least theoretically not bound by foreign governments. The problem with them was that I couldn't figure out how to host a static website on it, which was a bit of a problem. Another problem was that their pricing came in tiers, meaning that if I wanted to upgrade from one website to two, I'd have to spring for a lot more infrastructure which I didn't like. The

So the final race was between DigitalOcean and AWS. With this, it ultimately came down to pricing. DigitalOcean has reasonable pricing, but they start you off at a minimum of 5$ per month for 250GB, which is astronomically more than I need. In contrast, AWS has pay-as-you-go, so that's what I eventually decided on. Right now, this website is served from a simple S3 bucket which costs me less than a dollar per month, pretty neat right?

The final piece of the puzzle is that I added AWS' CloudFront, a content delivery network. I would have just not taken this step since I don't expect the demand for this website to be that high or widely spread, but using CloudFront was the only way I could have the website be served over HTTPS instead of HTTP and I was quite adamant that I wanted HTTPS.

One added benefit of using AWS is that it's an industry standard so that can go on my CV as well. It also gives me easy integration with other AWS services such as AWS Lambda, which I am planning to use to have this website also serve content security policies, but that is a story for another day.