Two articles hit my feed this week that got me thinking: Simon Willison's piece on delivering proven code, and a DEV post about losing our software...
For further actions, you may consider blocking this person and/or reporting abuse
Interesting, great piece - I just wonder how you go about optimizing, because your bill does not tell you exactly where that inefficiency comes from - all it would specify are network bandwidth usage, RAM usage, CPU usage ...
Do you try to optimize as much as you can "up front", before going live? Or do you see that your bill is "high" (but what's 'high' or 'low'?), and then you try to figure out what could be causing that?
In other words, I wonder what the recommended approach/methodology here would be ...
Good question—I learned this the hard way.
Upfront (before deploy):
wrangler tailto catch obvious slownessIn production:
Cloudflare's dashboard shows which endpoints are expensive. When something spikes, I check logs, profile that specific route, fix the obvious stuff (unnecessary API calls, bloated responses), deploy, monitor.
What's "high"?
For context: FPL Hub does 500K requests/day for ~$15-20/month. Target is under $0.00004 per request. If I see $50+, something's broken.
Real trick: Start lean. Way easier to add dependencies when you need them than rip them out when your bill's already high.
I now think in "cost per feature"—every new function gets a rough estimate of CPU time it'll add.
Thanks, excellent advice! I wonder if Cloudflare and similar platforms are more "developer friendly" (easier to use), especially their dashboards etc, than AWS - I just find AWS (it's tooling, docs, admin UI, dashboards - basically everything) daunting, but of course that's also because it's just a huge platform ...
Oh 100%. AWS is a nightmare if you're trying to move fast.
Cloudflare Workers:
wrangler init→wrangler deployand you're live. Dashboard shows requests, CPU time, errors. Done. Docs are actually readable.AWS Lambda requires understanding IAM, VPCs, API Gateway, CloudWatch... just to deploy a function. Then the bill is hieroglyphics.
I think edge platforms learned from AWS's mistakes. They optimized for "developer wants to ship code" instead of "enterprise architect designing distributed systems."
For FPL Hub, I'm one person—can't spend days configuring AWS infrastructure. Cloudflare was the only realistic choice.
Haha okay, what you say about AWS (specifically Lambda) resonates heavily with me - I'm involved in a project where we use AWS Lambda (and indeed CloudWatch), but we're using a tool/platform which simplifies things, and I've tried to stay away from VPC, avoiding all that complexity like the plague whenever possible - but, the complexity is evident nonetheless ...
Project isn't live anyway (far from it) although that's mostly because of NON-technical reasons ;-) but it does make me question the decision to use AWS, especially because no cloud but just a VPS would probably also get the job done ;-)
Yeah AWS is a beast, it's horribly complex, I think only people who are certified in it can "love" it, or tech startups/companies that are very "technical", enterprise architects as you say - mere mortals, independent developers, no not really ;-)
Yeah, using a tool to abstract AWS is basically admitting "this is too complex" 😆
The VPS vs serverless debate is real tho. For your case. if it's not even live yet and you're questioning AWS.honestly just spin up a $5 Digital Ocean droplet and ship it. You can always migrate later if you actually need Lambda's scale.
I only went serverless because FPL Hub hit scale problems early. If I was at 1K requests/day? VPS all the way. Simpler, predictable costs, SSH in and fix things.
The dirty secret. most projects claiming they "need" serverless don't. They need to ship and get users first. Premature scaling is real.
Cloudflare Workers worked for me because I was already at scale and needed it. But if you're not live? Don't torture yourself with AWS complexity for hypothetical traffic.
Ship on a VPS, prove the product works, scale later if you actually need to.
Wow this hits home lol - you're just confirming what I was intuitively already thinking ...
"For your case. if it's not even live yet and you're questioning AWS.honestly just spin up a $5 Digital Ocean droplet and ship it. You can always migrate later if you actually need Lambda's scale."
Yeah maybe we should, and the rest of what you're saying in your comment is also spot on - I'm honestly baulking at AWS's ridiculous complexity, even though the tool we use sweeps it pretty much under the rug ...
And for now there's nothing that indicates we even remotely need this kind of "scale" - Lambda, for us, right now, is more or less just hype/YAGNI/premature optimization ...
The good thing is that our app should be easy to "port" to a VPS, there's no AWS vendor lock-in yet - and if ever we need it, it should be easy to "port it back" to AWS/Lambda ...
Yeah the insane amount of complexity of the AWS platform is pretty much putting me off, mainly because I'm just not interested in becoming an "AWS expert" ;-)
"I'm just not interested in becoming an 'AWS expert'"
This is the real cost nobody talks about. Learning AWS isn't a weekend.it's a career specialization.
If you're building a product, every hour learning IAM policies is an hour NOT building features or talking to users. That's the actual waste.
Since you have no vendor lock-in yet, honestly just ship on the VPS. Get real users, real feedback, real revenue . If you blow up and actually need Lambda's scale. great problem to have, migrate then.You already know what to do. Pull the trigger lol.
Nailed it ... !
good information
Even if we're not building for edge computing, writing efficient software always has its merits.
Not everyone can afford a macbook with oodles of RAM. So if your next.js app consumes 2GB of it for rendering a form, then maybe the form crashes your user's laptop. Hey, you just lost a customer!
If someone trying to load your 100 MB SPA on a shitty mobile connection - they get frustrated after a minute and stop trying. That's another customer lost!
Always write efficient software, people!
Absolutely! You nailed the accessibility angle I should've emphasized more.
Edge computing forced me to care about efficiency, but you're right—it matters everywhere. The Nigerian users I'm targeting with VPN-Workers often deal with:
A bloated SPA doesn't just frustrate them—it literally prices them out.
The irony is that edge platforms' economic constraints (pay per millisecond) align perfectly with user constraints (limited bandwidth, older hardware). Building for one automatically serves the other.
We got spoiled thinking everyone has fiber internet and M3 MacBooks. They don't.