Cloudflare Workers are the future! 🏗

Ahoy! Just returned from a deep dive into exploring Cloudflare Workers and it was a great experience! I've been itching to give them another go as I've been following Deno and others from the sidelines for some time now.

At a high level, Cloudflare Workers enable traditionally complex, backend-intensive logic to be located closer to the frontend. This is not just another "do it all in JS" framework though. Rather, it's a paradigm shift that challenges how full-stack applications are built and deployed.

A simple blog example 📝

I love dev.to - the CMS/IDE and community are all wonderful. But as I write more content I also want a way to display and share it via my own website. This ended up being a perfect application for this framework: taking on a complex set of features with a low-code solution.

Here's what I managed to get my little project to do (easily!) using Cloudflare Workers:

• Fetch up-to-date data from dev.to's API
• Create simple article/detail routing layer
• Render components using JSX on server
• Deploy automatically to custom domain (using GitHub actions)

Here it is in action: blog.bryce.io.

And here's the repo if you want to poke around the code:

brycedorn / blog

Using Cloudflare Workers to proxy dev.to posts and cache at edge

A thriving ecosystem for worker tooling 🪚

I used hono (a wrapper around miniflare) to handle some of the boilerplate around request and routing logic. It's also refreshingly fast! 🔥

The project also fully supports TypeScript. Nano JSX is an ultra-fast JSX library that works great with SSR (and written in TS). And wrangler makes deployment dead-simple, and integrates with the wrangler-action to automatically deploy upon any changes.

Why this is cool 🪄

As Cloudflare Workers are an on-demand serverless resource, they only run when a request is made. And since they run at the edge, this mean caching is baked-in!* At scale, this means lots of resources and compute time saved without any additional effort on the developer.

No servers = local development (and deploys) can happen without any spin-up time. My last deploy via GitHub Actions took less than 30 seconds (and the build step took 0s 🦄). Hot reloads during development actually feel instantaneous too.

Next I want to experiment with more client interactivity but I had a wonderful time building this small static/SSR project! 😇

---

Anyways, I hope this doesn't go against dev.to's API guidelines (let me know otherwise). And here are a bunch of worker examples to explore if this piqued your interest. I'm looking forward to using them more in the future!

*Edit 6/3/22: turns out this note about caching was not true. I wrote about manually adding edge caching here.

Comments

[John Carroll]

Edit:

This comment is no longer applicable

Original:

So, this article largely contains incorrect information.

The term Web Worker is part of the HTML spec and has a specific, defined meaning. The API for Web Workers is built into your web browser and has been for over 10 years. I expect many web developers, like myself, expected this article to be about Web Workers. Instead, this article is talking about Cloudflare Workers and other types of cloud based, proprietary serverless functions.

I imagine you're conflating the names of two different things because "Cloudflare Worker" seems semantically similar to "web worker" (even though they are unrelated) and also because Cloudflare chose to mimic the service worker API when creating their Cloudflare Worker product (even though the two are unrelated and, in general, do not overlap in use cases).

Service workers are an on-demand serverless resource: they only run when requested. And since they run at the edge, this mean caching is baked-in!

This is incorrect. While Cloudflare Workers do this, service workers do not and cloudflare workers are not service workers. Service workers run inside the web browser and not "at the edge" (unless you're using the term "edge" facetiously here). The Github Action you linked to is deploying your code to a Cloudflare Worker which is unrelated to a service worker.

I imagine all of this confusion stems from the fact that Cloudflare chose to mimic the service worker API in their product. But that is where the similaries end. They do not have the same use cases. One runs on a server and the other runs in the browser. One is not a replacement for the other. Importantly, Cloudflare Workers should not be referred to as "service workers" since, again, they are different (and unrelated) things.

[Bryce Dorn]

Thanks for your comment - I updated the references to web workers to "Cloudflare Workers" to avoid confusion (the "worker" namespace is a bit crowded 😅).

[Milan Andric]

Does hono support deno? Wondering if there is a way to deploy the blog using pure deno (remove nodejs/npm dep)?

[Bryce Dorn]

It's tightly coupled to miniflare which is only designed for Cloudflare Workers. I originally wanted to use deno but deno deploy didn't play nice with custom domains.

[Yusuke Wada]

Hi! I'm author of Hono :)
I'm planing to make Hono spports Deno. I don't know if I can do it. Deno is using Service Worker like API too, it has a possibility.