If you're anything like me, you've probably spent way too many hours figuring out the "simplest" way to deploy apps without losing your sanity. I've been bouncing around options and lemme tell you: it’s been an adventure!
Why is deploying stuff still complicated? 🤦♂️
You know the drill:
- Deployment pipeline: CI/CD/k8s. I know, sounds easy until you get into YAML hell.
- Logging and monitoring: Do you like looking at your Datadog bill?
- Database setup and management: "managed" databases... still feels like babysitting at times.
- Secrets and env variables
- Horizontal scaling
- The list goes on...
What have I tried?
Options that I have used/experimented with at different workplaces:
- Hetzner/DigitalOcean/Linode: affordable, but SSH-ing into servers to deploy a simple app feels so 2010 😅
- Render/Netlify/Vercel: Great UX but I think they're overcharging.
- Heroku: do you even know how many Dynos you need to run your app?
- AWS Elastic Beanstalk: not gonna deny, this was one of the nicest solutions as it manages an EC2 instance for you (with no additional fees). One downside top of my mind: I have to deal with lots of YAML
- GCP Cloud Run/AWS Lambdas: Cold starts... 🥶
- Kubernetes: Nope, nope, nope. Let's not ruin our mood today with Kubershites 💩
One common theme? All these solutions still need extra tools for production-grade stuff: secrets, DBs, logging, ugh!
Enough venting!
Recently, I stumbled across Cloudflare Workers and decided to experiment with it. Spoiler alert: it's pretty darn cool!
So, what exactly is it?
Cloudflare Workers lets you deploy apps on Cloudflare’s global network with the least amount of effort.
How does it work?
Underneath, it uses V8 engine, the same engine powering your Chrome browser.
Fun fact: the deployment region is "Earth" 🌍 and Cloudflare magically runs your worker in the closest region to your users (thanks to Cloudflare's load balancer: Unimog).
But what about those dreaded cold starts? ❄️
From the docs:
Unlike other serverless providers which use containerized processes, Workers pays the overhead of a JavaScript runtime once. Workers can start roughly a hundred times faster than Node processes in containers.
Disclaimer: I haven't ping/load/stress-tested this yet. If you have, please write in the comments!
Let's explore some of Cloudflare stack 🛠️
-
Compute:
- Workers: Your basic app deployments.
- Pages: Static sites hosting.
-
Storage:
- D1: Managed SQLite with backups and everything.
- KV: key-value store.
- Hyperdrive: Connect your DB (like Postgres) and accelerate queries.
- Queues: Simple queuing.
- R2: S3 compatible blob storage.
-
Extras:
- Observability: Built-in logging.
- Secrets Management: Yup, secrets are handled.
-
Dev tooling:
- Wrangler: development cli to simulate running workers locally.
- Hono & OpenNext: Frameworks by Cloudflare to streamline your dev experience (OpenNext is like Next.js but deployable anywhere).
To me, this sounds like most of the tools you would need to deploy your app in one place!
Have I built something or I just wanna talk about it?
Couldn't resist! I whipped up a marketplace demo app (it happens that I work at the largest marketplaces in Sweden: CDON & Fyndiq).
Yes, I did vibe-code the UI with Lovable and wrote lots of the code using Cursor 😄
You can visit the website here (unsure for how long I'll keep this available): https://marketplace-edge-shop-frontend-integration.alnyaser2.workers.dev/
Architecture
I've tried to make a micro-service architecture aiming to try out different services from Cloudflare:
This architecture follows CQRS (Command Query Responsibility Segregation) architectural pattern to keep write operations separate from read ones (merchants update products, customers browse without hiccups).
Here's my marketplace-edge repo. It's a mono-repo with the above three apps:
- inventory-api: Hono api for merchants to manage products.
- shop-projection: Hono api for customers to get products.
- shop-frontend: OpenNext frontend/UI for customers to browse the products.
Small hiccups I found:
- Shared queues: Running multiple apps locally (with shared queues) was a pain. I tackled this by creating a script to run two apps using the same wrangler instance. It would've been easier if I could run each app separately and point to the same wrangler local environment (which is a directory).
- Testing: integration tests for queues were tricky. I ended up mocking instead of integration testing. I wish there was an internal tooling to make sure everything is working in an integration test.
Sounds amazing, right? But wait... 🤔
Cloudflare Workers isn’t the silver bullet for everything. Sorry to burst your bubble! Here’s when I think it's good:
- Quick deployment, minimal hassle.
- Cost-effective (both engineering and compute).
- You're cool with system design around Cloudflare stack.
Some limitations:
- Can't really build apps that run 24/7. For example: a Kafka consumer that continuously polls new messages to process (please correct me if I'm wrong in the comments). You might achieve the same result with Cloudflare Pub/Sub, but it's beta as of writing this article.
- Only three languages supported:
- JavaScript/TypeScript.
- Rust.
- Python (barely usable, standard lib only).
Containers coming soon might fix that though; keep an eye out.
Your turn! 💬
What do you think?
Could Cloudflare Workers change the game for deploying your apps? Any horror stories from your own deployments? What other options would you recommend?
Let us know in the comments. I love hearing about everyone’s tech adventures!
Top comments (0)