Migrations: from Wordpress to Firebase
Ian Hellström | 11 December 2019 | 4 min read
As of December 2019, databaseline.tech is served from Firebase to deliver all content securely, reliably and quickly, for free. This article details the background and various reasons for the migrations that have happened over the years.
May 2014 – January 2017: Wordpress.com
In 2014, I had enough material on the challenges of data integration, which turned into the first four-part series on Databaseline. Since I had no idea whether there would be many more posts, I decided to go for a lightweight solution: a hosted blog platform. Back then, the choice was essentially between Wordpress and Blogger. I had had some experience with the latter and remained unimpressed of it, so I decided to give the former a whirl.
It proved a great way to get started with a blog. I did not have to worry about anything except creating content.
After about three years, I felt that it stopped serving my needs. I preferred to write posts in Markdown, both online and offline. I did not want to worry about the availability of network connections or formatting. Moreover, I prefer to have posts versioned with git. I therefore ended up copy-pasting Markdown into the Wordpress.com editor, which more or less interpreted the text correctly thanks to a plug-in. Images and code often ended up requiring some effort to get right though.
Moreover, the ads at the bottom of each post were small but annoying enough. I felt they made the blog look like a clickbait site, which is not what I had intended at all.
February 2017 – November 2019: Bitbucket
To take back control and simplify my process I wanted to use Bitbucket. Similar to GitHub Pages, Bitbucket allowed me to serve static content directly from a git repository. All my public and private repositories were already on Bitbucket, so it made sense to have everything there. The solution was also free, but without ads.
The only decision to make was what to use to turn the text into HTML. The requirement of a simple text format for creation of content led me to look at either Markdown or reStructuredText. I had already discarded LaTeX. In the meantime I had started oracle.rtfd.io, which used Sphinx and reStructuredText. However, I found reStructuredText a bit tedious compared to plain ol’ Markdown. So, Sphinx was out.
After a few (local) experiments I went with Jekyll. It was a low-fuss option that used Markdown for actual content and mostly used a configuration file to wire up the website. A rich ecosystem of plug-ins and customization options with Ruby sealed the deal.
I had one private repository for the Markdown, including notes and drafts.
During the build process (with
jekyll build) the static website landed in a dedicated folder that was
rsync‘d to a public repository that was used to host the blog on the web.
To be fully compliant with GDPR and ePR by default, I dropped analytics tracking altogether.
A few months after the relaunch I stumbled upon Hugo, but I stuck with Jekyll. Yet another migration of roughly fifty posts would be too much of a hassle, without any significant benefit. I did end up using Hugo successfully for another endeavour of mine. Check it out if you like to read fiction.
December 2019 onwards: Firebase
Around Black Friday of 2019, I bought the domain databaseline.tech. I wanted Databaseline to be accessible more easily and, most importantly, have a permanent residence on the internet. Unfortunately, Bitbucket never supported custom domains for static hosted repositories. I briefly considered either moving my blog to GitHub or mirroring the (static) website there; GitHub Pages does support custom domains. Frankly, that felt like too much of a workaround to be worthwhile. There had to be an easier way!
Based on my experience with a cost-effective way to store petabytes of data in GCP, I instinctively went for Google Cloud Storage, which offers quite a bit of storage for free and it can host static websites. It does not allow CNAME records on root domains (i.e. only databaseline.tech instead of www.databaseline.tech), but I deemed that an acceptable compromise. The main issue turned out to be that GCS cannot serve content through HTTPS when using a CNAME redirect. Visitors to Databaseline would see warnings in their browsers, which does not inspire confidence and is a bit silly for static content. Moreover, the free tier for GCS only allows multi-zonal buckets, which means I had to serve content from a single region (e.g. Europe or USA). People on another continent might need to wait a bit longer.
Thankfully, GCP offered solutions to my problems. Thanks to excellent instructions, the migration from GCS to Firebase Hosting was painless. I had to change three lines in my deployment script and that was all there was to it. With SSL baked in, Firebase serves all content on Databaseline securely.
I did integrate Google Analytics again, because I had no idea how many people actually visited these pages, especially after the various migrations. I have no intention of using the data to make money or ruin the minimalistic experience by plastering ads all over. Databaseline is work of love and that’s how it will stay.
The original databaseline.bitbucket.io will remain in place for the foreseeable future and only redirects to databaseline.tech. That’s mainly done to allow search engines to pick up on the change; it’s also to ensure people’s bookmarks keep working even if they do not drop by regularly. No new content will be added there though, so it is recommended you update your bookmarks and/or feeds accordingly.
From now on you can enjoy Databaseline through databaseline.tech and whether I’ll use another technology underneath should not be important anymore. It will stay on this address.
Thanks for reading!