Test driving Cloudflare Workers with a GitHub public repository monitor

In our previous article, Stupid simple serverless with usage-only pricing, we described how we ended up trying out Cloudflare Workers for a GitHub automation that notifies us whenever a GitHub repo is made public. In this piece, we detail the experience we had with the platform.

Code of the experiment and setup

The tool, called github-hawk, is published on GitHub and it’s surprisingly simple (and useful!). Setting up the project was trivial with the Wrangler CLI that Cloudflare provides.

Running the tool involves setting up an account with Cloudflare, setting the variables, called “secrets” and publishing the worker. It was smooth without surprises.

What exactly are Cloudflare Workers?

Cloudflare Workers are a variation of Web Workers. This variation is meant to be used server-side, distributed across the fleet of edge nodes belonging to Cloudflare, which is one of the major CDNs.

This means code gets executed as part of a V8 JavaScript engine instance, which in turns means they run JavaScript or WebAssembly code. Besides the usually expected features like a JS runtime and network access, workers also support a global key/value store called … Cloudflare Workers KV.

Unlike conventional containerization methods, isolates have much lower overhead per user process. By no means is this specific to Cloudflare. For a more in-depth overview of workload isolation methods, see this article from fly.io. In the context of that article, Cloudflare Workers isolate workloads through a language runtime

Analysis

The simplicity of the implementation proves that the approach is workable. Being a simple forwarding proxy, there’s no concern regarding costs or performance. Cloudflare’s documentation is quite good for getting started and their CLI tool, wrangler, is also easy to use.

However, there are some drawbacks that make it less than ideal as a general computing platform. The debugging experience leaves a lot to be desired while developing locally. This stems from the fact that all development code actually runs in the cloud, which means logs have to be remotely captured. It’s not a big issue with published workers, but with development workers it is, because by default, exceptions are swallowed and the only way to get them is to catch and log them yourself or, alternatively, hook up a centralized service for this purpose.

Being derived from a client language runtime (V8, which is Chrome’s JavaScript engine), it comes with a design baggage biased towards the client-side. For example, there is a crypto API, but it’s based on the Web Crypto API, which lacks features that are useful on the back-end. Take the crypto package from Node.js, which has a timing-safe comparison function, which is missing from Cloudflare Workers. This would’ve been useful in the isSignatureValid() function.

There are some use cases that still make the platform very attractive. The main idea is that with these custom workers, the level of flexibility in the behaviour of the CDN is increased dramatically. Unlike a conventional configuration-based approach to CDN rules, workers enable websites to granularly and intelligently define CDN behaviour, including caching policies and filtering logic. With some extra investment, it can become a promising approach not only for deploying “intellligent” CDN behaviour but also for general computing “on the edge”.