While putting together DBaaS Review I’ve been wondering how to sustain it. At some point the bills must be paid. I began evaluating some monetization options.

I considered and rejected display ads. There are privacy concerns, and my target users are likely to be banner-blind and/or blocker-savvy. That said, I have enabled privacy-friendly Plausible Analytics on both that site and this one here. One can’t understand or improve on what one doesn’t measure.

Inspired by content producers like Jason Kottke and John Gruber, I’ve decided to try direct sponsorship. Jason uses a service called Memberful, but I’m going to start small and see how it goes.

I’d like to give people the opportunity to sponsor or work with me personally too. That’s why I added the “Support” button in the footer. Here are some income/monetization options I researched:

• Gig work: UpWork, Fiverr
• Donations: Ko-Fi, Patreon, Donorbox

TL;DR: go check out DBaaS Review and let me know what you think.

A couple of years ago I started tracking DBaaS prices in a spreadsheet. Besides AWS RDS, it just seemed like there were more and more good options being announced each month. Finally in 2019 I cleaned up my data and turned it into an interactive calculator on this website.

There were a few limitations with the simplistic approach, though. I was originally interested in the sub-$50/month market segment, but many interesting offerings are well above that. When you add more dimensions (like regions, replicas, and commitment) the number of potential options balloons. It was no longer feasible to keep the data in a static single page application.

I bought dbaasreview.com and deployed new static site to Cloudflare pages, later to Render. I investigated using Cloudflare workers for the API, but for now deploying a separate API from a separate repository was more straightforward. I’m using Render’s free tier, so the main drawback is that the API shuts off after a few minutes of inactivity.

The vast majority of the work is importing all of the different product plans into a single unified database that powers the API behind the calculator page. I spent two days puzzling over Azure’s pricing API, I’m not looking forward to doing the same for AWS and GCP. Since the data is pretty small (< 5MB) and read-only, the API uses a SQLite database deployed alongside the application, ironically. If and when the project outgrows this, I will scale up API replicas.

Anyway, it’s been fun and interesting to build and maybe will turn into a consulting gig or something, who knows.

TL;DR: Reversible Jacket is a useful pattern for developing a web frontend UI and backend API simultaneously, and here’s a demo.

Tools like esbuild and Vite make developing static frontend web applications enjoyable, and there are tons of starter templates out there for them. But if your frontend UI and backend API are being developed together as two tightly-coupled halves of a monolith, how do you structure your project to handle both the development phase and the production phase without tearing your hair out?

Voilà: the Reversible Jacket. The idea is that the frontend dev server proxies API routes to the backend server during development, while in production the roles are reversed and the backend hosts the frontend’s static assets and the API routes as single-origin app. The README explains why that’s a good thing and how this reference implementation works. This could be useful for anyone making a Jamstack app using the BFF pattern, regardless of their specific tech stack.¹ In my experience, a Reversible Jacket codebase is a pleasant and productive workspace once configured.

This is nothing revolutionary. Maybe this pattern is so obvious that nobody bothered to write it down, or it is already named something I’m oblivious to.² If not, I think that “Reversible Jacket” is descriptive and memorable. Here are some tools I found that solve similar problems:

• The Vercel CLI has a dev command so you can test serverless functions locally.
• The Netlify CLI has a dev command to run a local dev server with Netlify’s proxy and redirect rules, and apparently you can test functions locally too.
• Supabase launched edge functions recently, and you can develop locally using the command supabase functions serve.
• The Stackery CLI allows for local development.
• The AWS SAM allows you to invoke lambda functions locally with the command sam local invoke.

All I’m trying to say is that there seems to be some momentum for this kind of smooth local development experience. Those proprietary tools above might not be much help to a UI/API destined for a platform like Kubernetes, ECS, GCR, Fly.io, Render, etc. We owe it to ourselves and the maintainers that will eventually inherit our codebases to invest in good DX.

Footnotes

1. Or, this could be the final thing that sends you screaming into the arms of Hotwire or Phoenix. ↩

2. That would be embarrassing, but I would like to know if so. Please reach out. ↩

One of my reasons for having a personal website is to have a place to experiment with technology. I’ve been using VuePress for a while even though it’s more of a documentation tool than a personal blogging tool. Last year I upgraded VuePress from v1 to v2, and this year I had my eye on VitePress. I began the migration but then the Astro project caught my attention. As you can see from this post, I’ve moved my personal site over from VuePress to Astro.

I think that VuePress and VitePress are probably not the the right tools for what I’m specifically trying to do. If the goal is simply to put some markdown files on the web, then just about any SSG is fine. Astro is a little bit closer to Nuxt or SvelteKit though, and I appreciate what they’re trying to do.

Here are a few things I learned migrating from VuePress to Astro and Tailwind:

• You can embed components in Astro’s markdown, you just have to import the component in the frontmatter.
• Instead of wrapping non-SSR components with <ClientOnly> tags, Astro uses a directive. It would look something like this: <YourComponent client:only />
• Both Astro and VuePress choose some markdown extensions, but VP gives more out of the box. For example, to enable emoji shortcodes (:+1: = 👍) I had to install and configure remark-gemoji.
• Local search is not not included like it is with VP. I don’t miss it, but it could be a dealbreaker for some.
• There doesn’t seem to be an easy way to restore VuePress’s custom containers. Maybe I overused them.
• If you used a lot of inline code and now you’re using Tailwind typography, you have to override the part where it helpfully adds graves back in. Otherwise all of your inline code will look `like this`.
• I got caught on a known issue (#2146) about embedding fonts from npm packages, but there’s a workaround.

Here’s the astro.config.mjs that worked for me (see update for more recent version):

import { defineConfig } from "astro/config";
import vue from "@astrojs/vue";

export default defineConfig({
  buildOptions: {
    site: "https://barnabas.me",
  },
  integrations: [vue()],
  markdownOptions: {
    render: [
      "@astrojs/markdown-remark",
      {
        remarkPlugins: ["remark-gfm", "remark-smartypants", "remark-gemoji"],
        rehypePlugins: ["rehype-slug"],
      },
    ],
  },
});

Switching platforms is kind of like moving house. It forces you to take stock of what you have and clear out junk you don’t really need. If it’s still in the box 📦 since the last time you moved, maybe it’s time to throw it out. 🗑️

I just updated my DBaaS article with a new entry: Fly.io. They caught my attention a couple days ago via HN. I really like what they’re doing and wish them the best.

I updated my calculator code with their pricing and was shocked how much they undercut everyone. Then after I found and fixed a bug, they settled in to a more reasonable spot. Still, they now offer a generous free tier that they’re rightly proud of.

Fly.io’s CEO Kurt Mackey replied to the question “are you running your own servers?” in that HN discussion:

We run our own servers. It took a lot of work but it’s really making life easier now. I’m not sure we could offer a free tier like this on top of another cloud.

In fact, some of the other PostgreSQL DBaaS providers offer a free tier but do not run their own servers. How and why do they do it? I think that would be the 80/20 rule or Pareto principle in action. I’m guessing that they must subsidize all the free accounts on the low end with the big spenders trapped into overpaying at the high end. It brings to mind the image of whales being harpooned in a cove.

I just upgraded my personal site from VuePress v1 to v2. Some things were very easy, some were not. Here are some of the things I learned from this project:

• The migration guide for VuePress is an excellent resource.

• Since this migration also entails an upgrade for Vue, the Vue migration guide Breaking Changes section will be useful too.

• Filters are no longer supported in Vue 3, but I had a bunch of those. ☹️

• The biggest fundamental change (IMO) is that $site.pages is no longer available “for scalability concerns.” I get that, but this makes writing components that show a list of pages difficult, but not impossible. The workaround is to use a temp file.

• Customizing the look and feel is super easy now that VuePress uses CSS variables.

• This fulltext-search plugin is not compatible with v2, but you can make the page content (not just the headers) searchable by configuring the search plugin like so:

    [
        '@vuepress/plugin-search',
        { getExtraFields: (page) => [page.content] },
    ],

• VuePress v1 used to automatically register components in the .vuepress/components directory. To get that back you have to use the register-components plugin.

• The @vuepress/blog plugin is not compatible with v2 (and I think it would have to be rewritten), but there are some nice features built in to VuePress that make me not miss that so much, such as extendsPageOptions.

Once VuePress v2 is out of beta there’s a number of documentation sites at work we’ll probably want to migrate. I wanted to know how big a job that will be, so I used this site as a test. There are still some rough edges, as evidenced by this bug I found while upgrading (update: fixed in 2.0.0-beta.26). If you are interested, here’s the PR for this upgrade.

The other week my MacBook Pro’s hard disk died. Even though it was one day past warranty, the Apple Store technician was kind enough to fix it free of charge. I learned the following things through this experience:

1. If you pay for your own Apple hardware (as in, not under the protection of an IT department), you have no choice but to purchase AppleCare. “Ah but I do have a choice,” you say, “or why would they let me decline coverage?” True. You also have the choice to cover yourself in Worcestershire sauce and swim in a tank of piranhas.
2. The cost to you to replace a 512 GB hard disk for a 2017 MacBook Pro is $740 + 1 week of No Laptop. The cost to your spouse is arguably much higher, if you are the complainy type.
3. Apple Stores’ pandemic protocol is very good: plexiglass, limited customers allowed inside, constant surface wiping.
4. Being inside a nearly empty Apple Store is eerie and sad. The music doesn’t help.
5. Having all of your code in source control and your files in the cloud is not the same thing as having your computer properly backed up.
6. An iPad is no substitute for a laptop. Not even close.
7. Hardware problems can really sour one’s mood.
8. Even if you tell the technician that you want macOS Catalina not Big Sur, you should double-check that they didn’t helpfully install Big Sur anyway.
9. To downgrade macOS, you’ll need a blank USB flash drive, these instructions, and an abundance of calm serenity.
10. Modern software and hardware is simultaneously an astonishing miracle and also the worst thing ever.

While reading about DigitalOcean’s new App Platform, I stumbled across a cool new PaaS called Render. They launched in 2019 and offer a compelling alternative to Heroku. I just added them to my DBaaS Calculator.

They’re the only option in my calculator under $10/month, which is a big deal when you’re just starting up a proof-of-concept side project. It’s true you can get a shared DB from ElephantSQL for $5, as long as you don’t need PostGIS. Anyways I hope Render gives Heroku a run for their money.

Last week I repeatedly had a sense of déjà vu, especially whenever I would begin a new email or text message. It happened frequently enough that I began to worry if I was losing my memory. So, I started writing a blog post about how vital a good memory is, but before I knew it I had written far too much. So I put it in a separate article and then I kept fussing with it for too long.

But then I remembered that articles are meant to be updated continuously, so out it goes. Now I just have to remember to update it later.

With this post, I’m restarting my blog. Maybe the “articles” format was too ambitious and keeping me from writing more often. At least, that’s the most self-sparing explanation. I say “restart” because I’ve blogged before on Wordpress and Tumblr, but not recently.

Technically speaking, I enabled a Vuepress plugin and embedded this blog into the existing site. If you’re interested, the source for this site is public, and the configuration to make this work is mostly in docs/.vuepress/config.js.

Personally speaking, I’m glad to have a place to journal again. I’m also thankful my only recurring cost is the annual domain name renewal.