12 in 24 January: Cloudflare Zaraz Managed Component for Countscale Open Source Analytics

An overview of my 12 in 24 January challenge completion.

January 12 in 24 Status Update - 12 in 24 is a year-long challenge started by Jacob Windle in collaboration with TriDev and Founder's Forge.

Start of Month

I started the month working on mackenly/rss-aggregator-api and have made quite a bit of progress. The goal is to build an API and search tool for aggregating various blogs for the TriDev site. I am still working on this and will likely do it in February.

End of Month

I reprioritized about halfway through to creating a Managed Component for a project called Counterscale. If you’re not familiar with Counterscale, it is a Plausible/Fathom-like self-hosted alternative based on Cloudflare Worker’s Analytics Engine. Virtually $0 cost and exactly what I need for some of my smaller sites. Managed components (MC), on the other hand, are a standard-ish developed by Cloudflare for 3rd party script managers. Finally, Zaraz is a Cloudflare-acquired YC startup whose goal is to increase the performance and privacy of 3rd party script managers. It’s like GTM but better. Zaraz uses MCs to define 3rd party tool methods. You can think of it as object-oriented tracking and analytics.
My project comes in by creating a managed component for Counterscale. An MC enables fully serverside analytics and built-in consent/privacy management. Works great, preserves privacy, and doesn’t slow anything down.

https://github.com/mackenly/counterscale-managed-component

Challenges

If that’s all you want to know, you can move on, but there were a few challenges that I ran into that I had to overcome worth sharing:

Cloudflare’s MC to worker build tool has a bug on Windows with their node script spawning subprocesses. It was a quick fix: PR
Cloudflare gives two options for creating custom Zaraz workers: Using the previously mentioned build tool or manually creating it by adding your code to a template. Unfortunately, the build tool ended up not working with my MC because I needed to rely on some Worker bindings not in the default build tool (specifically service bindings). My solution is twofold:
- For now, I set up a custom worker template and build/deploy using standard GitHub Actions. The code. Works great, but it is hard to update if the MC template changes.
- For a longer-term solution, I created a PR to add support for using a custom wrangler.toml in Cloudflare’s build tool. I’m really not sure why this wasn’t done already since there’s a big use case for needing bindings. Ultimately, when/if merged, this will make the build tool much more flexible and eliminate the need for overly complex build and deployment steps.

I’ve still got some more work to do for this one and expect it to be something I continue to maintain for a while, but even with the build/deployment trouble, I’m happy with this because it saves me money, consolidates my stack, and gave me a good opportunity to work on Zaraz. 🎉