Why SheetsAPI Runs on Cloudflare Workers
The architecture behind GKit SheetsAPI: why we chose Cloudflare Workers over traditional servers, and what that means for latency and reliability.
The question every developer asks
When you're building an API proxy — something that sits between your app and Google Sheets, validates API keys, and forwards requests — the obvious choice is a Node.js server on a VPS or a Lambda function. We went a different route: Cloudflare Workers. Here's why, and what the tradeoffs look like in practice.
Edge compute vs. a traditional server
A traditional server (EC2, a VPS, a container on Fly.io) runs in one or two regions. A request from Singapore to a server in us-east-1 travels roughly 250ms before it even touches your code. Lambda helps with managed infrastructure but doesn't solve the geography problem unless you replicate across regions yourself.
Cloudflare Workers run at the edge — on Cloudflare's network of 300+ locations worldwide. A request from Singapore routes to a nearby Cloudflare data center, not all the way to Virginia. For an API proxy, this matters: the round-trip to the Worker is short, and the Worker then makes the outbound call to Google Sheets' servers from the same edge location.
No cold starts
Lambda functions spin up containers when there's no warm instance available. On a low-traffic project, the first request after a quiet period can wait 1–3 seconds just for the container to start — before your code runs at all.
Workers use V8 isolates instead of containers. An isolate starts in microseconds, not seconds. There is no cold start problem in the traditional sense. The first request of the day behaves identically to the ten-thousandth.
This is a real architectural difference, not a marketing claim. V8 isolates are lightweight because they share a single V8 process per machine and isolate execution at the JavaScript engine level, not the OS level. The tradeoff is that you cannot run arbitrary native code — everything must be JavaScript or WebAssembly.
KV storage for API keys
SheetsAPI needs to validate API keys on every request. We store them in Cloudflare KV — a globally replicated key-value store that's co-located with Workers at every edge location.
KV reads are fast because the data is cached at the edge closest to the incoming request. The tradeoff is eventual consistency: a key created or revoked in one region may take up to 60 seconds to propagate everywhere. For API key management, this is acceptable — a revoked key may work for up to a minute, but that window is short and the simplicity of not running a database is worth it.
The free tier is genuinely useful
Cloudflare Workers has a free tier: 100,000 requests per day. For a personal project or a small internal tool, this is enough to run indefinitely at no cost. The free tier does not throttle requests or add artificial delays — it's the same infrastructure as paid.
The paid plan ($5/month) raises this to 10 million requests per month and extends the CPU time limit, which brings us to the main constraint.
The CPU time limit
This is the honest part. Workers on the free tier have a 50ms CPU time limit per request. Paid Workers get 30 seconds.
CPU time is not wall time. A Worker that spends 200ms waiting on a network request (like the Google Sheets API call) only consumes CPU time while it's actually executing JavaScript — the await counts as wall time but not CPU time. In practice, SheetsAPI requests comfortably fit within 50ms of CPU time even on the free tier, because the work is mostly I/O: receive request, validate key in KV, forward to Google, return response.
If you were doing heavy computation — parsing large JSON, running cryptographic operations at scale — the 50ms limit would be a real constraint. For a proxy pattern, it isn't.
No origin server to maintain
There is no VM to patch, no container to restart, no load balancer to configure, no health check to write. The entire deployment is managed by Cloudflare. We use Wrangler (Cloudflare's CLI) for local development and deployment:
# Run locally with live reload
wrangler dev
# Deploy to production
wrangler deploywrangler dev starts a local runtime that matches the production environment closely enough that "works locally" almost always means "works in production." There's no Docker setup, no local environment approximation — it runs the actual Workers runtime.
What this means for you as a user
When you call https://sheetsapi.gkit.mreshank.com/api/spreadsheets/..., your request hits a Cloudflare edge location near you, the key lookup happens in KV at that same location, and the Google Sheets call goes out from the edge. The total added latency from the proxy layer is single-digit milliseconds in most cases.
If Cloudflare has an outage in a region, requests automatically route to the next nearest location. There is no single point of failure.
The architecture is not exotic — it's just the right tool for a stateless API proxy that needs to be fast and globally available without infrastructure overhead.