Always wondering how its going for folks that are using Cloudflare Workers as their main infra?
Then you'll still not beat a good self-managed VPS but you'll have someone else to blame
1) Creating and restoring backups
2) Unoptimized disk access for db usage (can't be done from docker?)
3) Disk failure due to non-standard use-case
4) Sharding is quite difficult to set up
5) Monitoring is quite different from normal server monitoring
But surely, for a small app that can run one big server for the DB is probably still much cheaper. I just wonder how hard it really is and how often you actually run into problems.
But to answer your question: running your own DB is hard if you don't want to lose or corrupt your data. AWS is reliable and relatively cheap, at least during the bootstrapping and scaling stages.
Cloudflare Workers support WASM, which is how they support any runtime beyond JavaScript. Cloudflare Worker's support for WASM is subpar, which is reflected even in things like the Terraform provider. Support for service bindings such as KV does not depend on WASM or anything like that: you specify your Wrangler config and you're done. I wonder what you are doing to end up making a series of suboptimal decisions.
The worker model made sense, so I developed the whole app around it. Now of course, knowing what I know today, I might have considered different options. But at the time, I read the description (and had some Cloudflare Workers experience) and thought this looked good.
Most people won't care because the extent of their debugging skills is console.log, echo, print. repeat 5000 times.
I don't agree. The first thing any developer does when starting out a project is setting up their development environment, which includes being able to debug locally. Stdout is the absolute last option on the table, used when all else fails.
while you should know this for anything you're proficient in, I usually reach for printf since it's usually quicker than messing with a debugger :)
Nothing is easier than setting a breakpoint in a line of code and running the app.
When a breakpoint is hit, you also have access to local variables and their state. Some debuggers even allow us to change variable values at runtime.
Using printf is effective, but far from being the best way to achieve anything.
https://tedspence.com/the-art-of-printf-debugging-7d5274d6af...
While some tools/frameworks might have more robust debugging tools, if you have a dynamic role within an organization, you may not find it worth the effort to set them up if your target platform is constantly changing.
One real world example of this from my own work in PHP - there is a tool/lang-extension called XDebug that is great and provides step through debugging, but historically, it has been a pain to configure. It's gotten better, but when I can just as easily add a few `dump()` statements that expose the same data, it's overkill. Very rarely do I need to actually pause the running request to debug something and 99% of the time, I just want to know the state of that object within an specific `if()` block and a debug log gets me that same information.
After that it doesn’t matter much which tool you use to verify assumptions.
Cloudflare in general is a DX mess. Sometimes it's dashboard doesn't even work at all, and is peppered with error messages. Workers + Wrangler + it's tooling doesn't even manage to put together a usable or coherent change log, which makes it very hard to even track how and why their versioning scheme should be managed.
Cloudflare is a poster child of why product managers matter. They should study AWS.