I made a further set of large changes to the blog engine today, but mostly in an invisible infrastructure component. I am planning to have a lot more data than I'll want to put into S3, granted its billing rate of 2.3 cents per GB-month isn't astronomical, but Backblaze B2s rate of 0.6 cents (and twice as large free tier) is significantly superior and will allow me to host a lot more data before it makes me want to clean things out.

The transition is already made and I had to make a lot of little tweaks to get it to a good place.

1. I agonized for what felt like 2 hours over what I perceived as an issue moving from S3 where I could configure S3 to be a public web serving bucket but still reject any request not coming from cloudflare's own IP ranges. The issue is:

   • If I want to make my content not publicly accessible from backblaze's web URL I have to make it private, and if I make it private I have to introduce a worker to cloudflare to perform the auth to my bucket. This is not an issue really, but with the Cloudflare free tier providing 100k requests a day it means I have to immediately upgrade to get 10M req/day to not be at risk of service interruption, and still pay 30 cents per million on top, not a problem at all from a cost perspective, but it's difficult to justify when other avenues are available for what is essentially free. If I have to pay cloudflare to use a worker to auth with backblaze in a way i wouldnt need to with S3, then that definitely changes the strategy because I could spend that monthly rate on storage at S3 instead and get comparatively more storage up to a point where it breaks even again.
   • In the end, I decided to try out backblaze but with a public bucket. There is no outside indication of what the name of my bucket is, and with really high free egress volume before charges kick in, someone wanting to make my life hard would need to figure out the name of my bucket and then transfer hundreds of TB downloading content from my B2 bucket before the billing would become an issue. I still think S3's bucket policy feature could make for a more robust system but, I think using a public Backblaze B2 bucket is probably the best balance since I can get a large amount more storage I can host for the same cost.
   • I looked into Cloudflare R2 as another prospective object storage backend but the cost is a bit higher and it actually seems like the same limitation also exists: I would need to use a worker to properly and fully secure access to the data.

2. Backblaze's web hosting functionality is more barebones and one notable missing piece provided by basic web servers that's missing is in the index.html redirects.

   • I worked around this by making my nav link generation more robust so that links to reach the parent pages of a blog post do now gain index.html paths.
   • The above plus manually updating all links in my pages to ensure they have index.html fixes all my links except one very important one, which is to go to the root page, e.g. stevenlu.net, I'd get a redirect to the backblaze website. Luckily I can easily address this edge case by adding a single page rule in cloudfront to redirect / URIs to index.html. Interestingly the target must be a whole page so I opted to just redirect the root URI to stevenlu.net, this means even if you go to www.stevenlu.net it lands at stevenlu.net.

3. I switched the static content sync mechanism in my "stage" script from aws-cli to rclone. It's a very similar sync call. Figured it's a good time to switch to get familiar with a tool that can portably target multiple cloud storage backends.

4. I tweaked some CSS to make font sizes more consistent and a few things such as,

   • cleaning up a FOUC that was happening for me only on the live site and not viewing it locally. That one was exacerbated by cloudflare's analytics code injection but not caused by it. I worked around it, though there is still slight FOUC affecting some stuff sometimes.
   • There is possibly still minor FOUC happening with giscus but it's pretty hard to reproduce.
   • At one point I had the dark mode code blocks broken (showing light background even in dark mode for them); that was rectified by ensuring the dark mode code gets initialized after including highlight.js, used for syntax highlighting of code blocks under marked.

5. Forgot to actually report in the earlier posts that I added a light/dark theme toggle to the site, though i did get hyperfixed on some interesting AI coding failure modes in the course of hacking on that earlier. I had aspirations for a more extensive set of theming features for the site, but i mentioned themability in passing to the AI and it added the neat and clean light/dark switcher and some good CSS variable architecture to facilitate it, so I wasn't going to say no to that. I think it will also actually make it fairly straightforward to expand it farther than just two modes in the future by doing some fun CSSOM stuff.

   • The way I ended up making theming work properly with giscus is actually pretty interesting: So there is an easy way to update the giscus current theme by sending a message. But what I was having trouble with was being able to assign the correct theme mode from localstorage to initialize giscus properly on page load. I am SSRing the entire contents of the page at launch time and not in response to any user input. That is certainly not about to change.
   • I had to prepare the following code into a script tag for insertion into the page. it's interesting this simple mechanism was necessary and sufficient to avoid having fully assembled script tags in string literals which would break out of the script tag that this is itself placed inside of.

   (() => {
     const giscus_script_tag_attrs = [
       'src="https://giscus.app/client.js"',
       'data-repo="unphased/Giscus-discussions-stevenlu.net"',
       'data-repo-id="R_kgDOM4lP6w"',
       'data-category="Show and tell"',
       'data-category-id="DIC_kwDOM4lP684Ci4bG"',
       'data-mapping="pathname"',
       'data-strict="1"',
       'data-reactions-enabled="1"',
       'data-emit-metadata="0"',
       'data-input-position="bottom"',
       'data-theme=' + (localStorage.getItem('theme') || 'light'),
       'data-lang="en"',
       'crossorigin="anonymous"',
       'async'
     ];
     const tag = '<' + 'script ' + giscus_script_tag_attrs.join('\\n') + '></' + 'script' + '>';
     // insert to end of page
     document.write(tag);
   })();
   

6. I am planning to explore the use of compression for file storage at rest but it's not hugely important for blog sites like this when the bulk of storage will be used by already compressed image formats. I will explore that in a separate site/app I'm going to host with a similar approach though.

I just found another issue which is that if i commit and push too quickly after saving a change in this project, the scripts are still running and the sync may end up deleting a bunch of HTML content that is still in the middle of being generated. This is actually extremely awkward but nothing some sentinel lockout files used for mutex logic wouldn't fix...