Website self-sustenance checkup

A key philosophy I want to follow with my website is for it to be “self-sustaining”. In this context, I mean having as little vendor-lock or dependency on third party services as possible. At the same time, I do want to take the advantage of great tooling and services so it’s a balancing act rather than going to one single extreme of doing everything myself or only using a minimal set of tools.

Why does it matter?

Have you ever lost something you’ve put time and effort into because the platform you stored that info went out of business or changed fundamentally enough that you decided to leave? I’ve been there bit too many times. I hate when that happens.

Let’s say, a hypothetical example, that you post everything to a social media platform and then its sold to someone who turns it into something you don’t want to be part of anymore. A wild idea, I know, but maybe you can imagine this happening.

In 2018, I created this current version of my website and over the past 6 years, I’ve been working on making it the central hub of what I create and from where I then share to other platforms. This approach is known as POSSE (Publish (on your) Own Site, Syndicate Elsewhere).

To make that possible for the long game, I need to make sure that I’m able to create content (like blog posts), build the site and deploy it to a server somewhere, regardless of any specific service being available.

Inventory of my current dependencies

Writing

Writing is my most critical feature on this website so it’s the one that needs to always work and have a backup solution available.

I currently use Notion to write my blog posts and Weeklies. It’s a third party tool that I’ve integrated into my website project through custom Javascript tooling. When I want to write a new blog post, I write it in Notion and then run two scripts to get it to my code repository. The first script is npm run notion query [word in the title] which finds all the matching blog posts from my Notion workspace and returns their ids. With npm run notion fetch [post id] , I then fetch the post through Notion’s API, run it through notion-render (with custom renderers) which outputs a file with YAML frontmatter and contents as HTML into my /posts folder.

While this workflow is highly dependent on Notion, in the big picture I have zero critical dependency here.

First, because I download the posts before building the site, I always have all my existing posts in my code repository and thus saved to version control. So if Notion would go down, I would lose exactly zero old posts.

Second, Notion is abstracted away from the core so it can be replaced with anything else. In fact, I’ve done that switch twice before: I started with local Markdown files, then switched to using self-hosted Ghost CMS and last year, switched from Ghost to Notion. If I want to write a post somewhere where I don’t have access to Notion, I can write it as a local Markdown file and it will be treated as any post written in Notion when the site is being built.

For my Weeklies, I currently use a Notion database and a similar flow than with my websites. The difference is that instead of rendering them as HTML, I store them in JSON files and the rendering happens when the site is built. From dependency point of view, the same is true though: if Notion goes away, I can switch to another tool that outputs JSON or write JSON by hand.

Building the site

My website is a static site. What it means is that I have separated the content and data from the layouts and a static site generator (SSG) - in my case Eleventy - combines them building the final HTML that gets then deployed to a server.

I love Eleventy and use quite a lot of its features:

I use Nunjucks templating engine to define the structure and while it’s not tied to Eleventy specifically, if I’d had to switch from Eleventy to another static site generator, I’d very much need to find something that supports Nunjucks – or I’d be spending an awful lot of time migrating from Nunjucks to something else.

I also have a lot of custom filters, collections and Eleventy plugins that I use and I have no idea how easy it would be to migrate to a different system while maintaining the features.

Eleventy itself is also a 3rd party dependency but since it’s a Javascript library that I download to my computers when I install it, it’s not gonna be able to “just disappear” like a SaaS service like Notion could.

It’s a dependency used at build time only so security vulnerabilities are not a problem in the same way as it would be with something that gets deployed to the server. So if Zach would abandon the project and delete all the files from the web, I could still use the existing, downloaded version forever locally.

Client-side dependencies

I’ve built a few things on the site that depend on active third-party service.

My site has an ability to show comments through Mastodon. If Mastodon servers are down or I get banned from all the instances, this will stop working. However, it’s not a critical part of my site, it’s only activated by manually defining it on per-post basis and it fails gracefully: a user doesn’t even know the comments are a possibility if they cannot be loaded.

Second, I use Webmention.io as a service to manage Webmentions for me. If someone links to my site and sends a Webmention, it will go to that service and from there, I can see them. These are not automatically visible on the website so from the reader perspective, nothing changes if it goes down. To maintain my happiness, I’d need to find a new service for it (or build my own) but there would be no critical failures nor degrading quality.

Deploying the site

Since my site is a static site: a collection of HTML, CSS and small bits of client-side Javascript, I can technically deploy it to any server out there.

In practice, there are a few ways I’m tied to my current provider.

I use a custom redirect format provided by the hosting provider. I have set up quite a lot of redirects:

• Some of them are quality of life things for browsing the site. You can go to /blog/roll or /blogroll and they both take you to the same place.
• Second, I have a few “shortlink” style redirects to external services that I use that have complicated or long URLs. These are not exposed anywhere and are just for myself.
• Third, I have “proxy” redirects: for example /youtube will always take to my Youtube channel and /@hamatti will take to my Mastodon account. These are handy because the exact URL in the service may change but people can always find me through these redirects.

I also show my “most popular posts” in the sidebar of my blog (on wide enough viewport) and in the stats page. These come from my provider’s server-side analytics. These are not critical nor important so if I’d switch to another provider, I’d first remove them from the website and then look into replacing them with another service if I felt like it.

Conclusion

All in all, I’m very happy with my current situation. All of the critical paths have backups and losing those dependencies wouldn’t even slow me down. All the dependencies that don’t have direct backups are not critical and thus, I don’t have to worry about them.

My main dependency that’s hardest to replace is Eleventy. The fact that I can run a local copy of it forever reduces the risk a lot.