Cloudflare Workers Explained

This is the video I wish I had when I was learning about workers. What do a web application, an API for your native app, and an AI agent have in common? They can all run on Cloudflare Workers. But workers are so unique, it's not super intuitive to understand them. So in the next few minutes, I'll explain how they work and why they're so powerful. The traditional Node.js server. Let's first look how you would traditionally host a web application or API. Here's a small Express.js app with a GET and a POST handler. Notice we have this app.listen handler, which means our process is running and actively listening for connections. To run this in production, you normally need a server. Then you could containerize this app with, for example, Docker or install Node.js and run it using a process manager like PM2 or Systemd. But in order for a request to actually hit your Node process, you would need a reverse proxy like Nginx or Kadi. This is fine and it works. I've run several apps myself like this for years. But how do you scale this? Scaling traditional apps. Our previous example works great for a small app. But once you start having thousands of active users, having one server is too risky and can easily get overloaded, leading to 500 errors and it's just bad news. To solve this, you can add a load balancer in front. That way you can spin up multiple servers and balance the load between them. But the issue is clear. You pay for compute whether you have a couple requests per minute or tens of thousands requests per second. So to summarize, at the very least, you need to have a single server running 24-7 to handle requests. Cloudflare Workers take a different approach. The bare minimum Cloudflare worker. Fundamentally, Cloudflare Workers are a JavaScript bundle that exports a fetch handler. Notice that there is no app .listen because there's not just one server listening. That's why we call it serverless compute sometimes. How does this work? Well, a user goes to yourwebsite.com and then they hit Cloudflare's network. Cloudflare sees that there is a worker for this URL and passes that request object to the fetch handler. It runs the code and returns the result. Done. There are a couple of huge benefits to this. One is cost. You're not paying if there are no requests. Because no code is actively running like in our traditional Node.js approach, you're simply not paying for any compute. Two is speed. Workers use v8 isolates. Unlike other serverless providers that use containerized processes, we run workers in v8 isolates. Now, we don't need to go into the technical details. Just know that any given isolate can start around 100 times faster than a node process on a container or on a virtual machine. Three is latency. Cloudflare's network is within 50 milliseconds of 95% of the world, with a large part of that under 20 milliseconds. So that means that serving your request is fast in San Francisco, in Amsterdam, in Tokyo, Melbourne, because each of these locations hold a copy of your worker that runs when a request comes in. This is also how your app can scale to millions of requests per second, because we load balance basically across the entire world. And I don't think anybody else does this. Four, infrastructure, or lack thereof, because there's no infrastructure to manage for you. Deploying is a single command. Check it out. I'm going to run wrangler deploy, and now it's live across the globe. Turning our Express app into a Cloudflare worker. Let's return to our Express app from earlier. Now, here's how we turn it into a worker. Instead of using Express, we'll use HanoJS, because it's awesome, but it will look very similar. See? There's very few changes, and of course, there's no .listen, because under the hood, it just exports that fetch handler we saw earlier. Other approaches. We're not limited to just APIs. You can return HTML, you can use React, and even full-stack frameworks like Astro, Next.js, 10-Stack Start, SvelteKit, and more. If you've seen my website, sidemugging.com, that's a 10-Stack Start application on workers. It didn't break a sweat when it was on the front page of Hacker News. Now, one final thing. Access to all Cloudflare's developer platform products through bindings. The final and arguably one of the biggest benefits of using workers is that you have access to all other Cloudflare products through what we call bindings. Do you want to run AI apps? Well, use workers.ai. Need to store things in a globally distributed key value store? Use KV. Do you need structured data? Serverless SQL? Use D1. Do you have an existing Postgres or MySQL database? Can use Hyperdrive. Do you need to send an email? Well, we have an email service. Oh, you want to do some asynchronous work? We have Cloudflare Queues. And there are many more products to discover that fit your unique needs. I hope that Cloudflare workers make sense now. That skill to zero means something. That global edge functions now make sense in the context of Cloudflare's global network. You can use Cloudflare Workers to build fully fledged web applications, APIs, or AI agents. Let me know what you think in the comments. And if this is clear or if you want to go more in depth. I hope the animations were useful. And yeah, let me know in the comments what you think. See you later.