[kStadler01]

I really like the offering that Cloudflare has with workers, but for me they just seem to be lacking some DX tooling/solutions. Debugging is hell, but for quick projects like this I'll definitely look into it again. These days Railway is my go-to for hosting "throw-away" projects.

Always wondering how its going for folks that are using Cloudflare Workers as their main infra?

[csomar]

I'm building my entire back-end on CF Workers. The DX was really frustrating starting out, but I'm using Rust/WASM, which means most of my issues get caught at compile time. My suggestion: avoid all the CF offerings (DB, Pages, KV, etc.) and stick with just Workers. They're pretty stable and reliable (more so than Cloudflare itself, hehe), and once you figure out their rough edges, you'll be fine.

[locknitpicker]

> I'm building my entire back-end on CF Workers. The DX was really frustrating starting out, but I'm using Rust/WASM, which means most of my issues get caught at compile time.

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.

[csomar]

The bindings are still done at the JS level. But to answer your question, I'm building a git workflow engine (kind of a lightweight GitHub Actions alternative; see https://codeinput.com). In that context, you get lots of events and payloads from Git/GitHub that typically require very little resources to respond to or relay.

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.

[huijzer]

What DB do you use? I tried the same for while but eventually gave up because it was incredibly restrictive and not much cheaper than a self managed VPS with some Docker containers. I mean the biggest thing that could happen to me is landing on the HN front page and a $5 per month VPS can manage that easily

[jddj]

You won't beat a good self-managed VPS with some docker containers unless you start adding criteria like SLAs and whatnot.

Then you'll still not beat a good self-managed VPS but you'll have someone else to blame

[DanielHB]

I am not much of a devops person but running your own DB in a VPS with docker containers don't you also need to handle all this manually too?

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.

[csomar]

My guess is some people have never worked with the constraints of time and reliability. They think setting up a database is just running a few commands from a tutorial, or they're very experienced and understand the pitfalls well; most people don't fall into the latter category.

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.

[h33t-l4x0r]

CF workers are v8 isolates FYI

[csomar]

AWS RDS. I have no intention of managing my own DB and the insanity that comes with that.

[NamlchakKhandro]

> Debugging is hell

Most people won't care because the extent of their debugging skills is console.log, echo, print. repeat 5000 times.

[hyperbovine]

printf() debugging is still considered a best practice in the eyes of many. I still remember being really surprised when I heard my famous (Turing award-winning) CS professor tell the class this for the first time.

https://tedspence.com/the-art-of-printf-debugging-7d5274d6af...

[yurishimo]

The thing about printf debugging is that it works universally. All languages, all platforms, all stacks. Even down to the lowest levels of most software, there will always be some sort of log available.

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.

[grey-area]

You missed out the important bit - think about the problem and data flow first.

After that it doesn’t matter much which tool you use to verify assumptions.

[locknitpicker]

> 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.

[compootr]

I don't agree! It's easiest to printf() things since you don't have to have tooling to debug every language you want to work with!

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 :)

[locknitpicker]

> I don't agree! It's easiest to printf() things since you don't have to have tooling to debug every language you want to work with!

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.

[soulofmischief]

You guys are probably gonna laugh me out of the room, but I use a combination of both printing and debugging tools when identifying issues.

[locknitpicker]

> I really like the offering that Cloudflare has with workers, but for me they just seem to be lacking some DX tooling/solutions.

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.

[koakuma-chan]

Yeah one time I tried do to something and the button didn't do anything, only after I opened DevTools I saw the error message in the response body.