OnlineOrNot Diaries 16
Max Rozen (@RozenMD) / November 29, 2023
Going too long between these diaries is a sure sign I've fallen down a rabbit-hole (this is when a developer is so focused on solving a problem, they keep digging without thinking to look back and evaluate whether the problem is worth fixing in the first place).
So it's a Wednesday morning here in Toulouse, and it's the first time in two months where I'm not thinking "oh man, I just need to fix this one thing and it'll be good", time to go over what's new.
To be fair to myself, I did get a lot done:
Wrote cron-jobs: the guide
I wrote the last diary totally sure I would spend the following weeks writing article after article for OnlineOrNot's cron job monitoring feature. I wrote a couple of small articles and realized "this should really just be a single guide", and so I combined them into Cron Jobs: the guide, and built a visual editor for cron jobs (for example: run cron every five minutes).
This hasn't taken off like I imagined it would (content marketing in the devops space is ridiculously competitive), but if it helps folks that do find it, I'm happy.
Started a YouTube channel
When I first started OnlineOrNot, I made a couple of YouTube videos showing how to use it. The videos had a few hundred views and were popular with new customers, but got out of date relatively quickly as I continued to build OnlineOrNot over the years.
Now that the interface has more-or-less stabilized, I started making YouTube videos again, essentially turning OnlineOrNot's documentation into a YouTube channel: @OnlineOrNot.
Some folks tend to prefer videos over written documentation, so my prediction is that this will help onboard folks (and act as a kind of "demo" for folks that are reluctant to meet with me to see what the product can do).
Focused on improving Status Pages
Speaking of OnlineOrNot's Cron Job Monitoring and my mission to actually finish my MVPs from the last diary, I wasn't particularly proud of OnlineOrNot's Status Pages until recently.
I built the feature in a rush a year ago, and was so sure it would start bringing in additional customers for OnlineOrNot.
It kind of did, but folks tended to use features as things to check off in a checklist when evaluating OnlineOrNot (in other words "Oh, you don't have feature X? You must not be as good as OTHER_PRODUCT that does have feature X...").
This kind of demotivated me at the time, and made it difficult to actually invest time in improving the feature when what most folks cared about was:
- Can you monitor our service?
- Can you stay online while the rest of the Internet is crumbling?
- Will your business stick around for 5-10 years?
In the last year I've focused on addressing these points, and the answers are: "yes", "yes, OnlineOrNot is highly available", and "I plan on doing this for at least the next 10 years, if not longer".
So in the last two months, I worked on improving Status Pages, and making it easier to add new features:
I started sending JavaScript, and no one noticed
Status Pages used to be small (around 13KB), but they weren't necessarily fast. It still took a few hundred milliseconds to query a database, and convert that result into HTML.
I managed this by completely disabling JavaScript in our React framework (Remix). While a fun thing to brag about, this actually slowed down my ability to release new features at a high quality. Charting libraries that support being server-side rendered are surprisingly rare (and buggy). Tooltips required a workaround that added hundreds of DOM nodes to the page, slowing down the app.
Recently I snapped, and started sending JavaScript to users. This means users download approximately 265KB when they first load an OnlineOrNot Status Page (a 20x increase). No customers have complained, instead, folks are happy about new features being shipped.
Completely on Cloudflare Workers
OnlineOrNot's Status Pages are built on Cloudflare Pages, but the API was a highly available service running in several nodes across the USA.
I recently moved the API entirely into a Cloudflare Worker using a mix of Hyperdrive, and Hono.
This has let me enable caching, is a significantly better developer experience (I can build and deploy the API in 1.9 seconds now, instead of 5+ minutes), and lets me dogfood products from my day job.
Dedicated staging environment
Status Pages work by having a Cloudflare Worker intercept all requests coming in, and routing them (with a special header encoding which status page to load) to a web app. Testing changes end-to-end locally with this setup was extremely difficult, the best I could do was unit test my Worker, and a few integration tests for the web app loading status pages.
I managed to get around this recently by building a copy of OnlineOrNot Status Pages' production environment: I now have a separate dedicated domain which has a Worker routing to a Cloudflare Pages app, and that talks to its own API.