You can't really run the Worker code without modifications somewhere else afaik (unless you're using something like Hono with an adapter). And for most use cases, you're not going to be using Workers without KV, DO, etc.
I've hit a bunch of issues and limitations with Wrangler and Workers locally over the years.
The deeper you get debugging, the more you have to reverse engineer, modify, even outright hack the target. Awesome war story, I know how good that must have felt.
Excellent points! I considered how to work in those cheap "Hail Mary" kind of commits. In then right situation those can be effective but it can also be incredibly risky. This is coming from someone with "Revert Revert Revert..." commits with my name tagged on them hahaha!
In Safari, I've had good success setting breakpoints in client side JS. The call stack isn't perfect, but usually it's at least enough to get me to the next step. The other thing I'd mention is request/response overrides in those cases you're debugging in production!
I agree with your take on cf - the idea is that cf could be seamlessly removed for whatever db you want to use. The important detail is that an individual user has the account and ownership of the data. I think long-term what I'm really trying to describe is an open API for the social/emergent web.
reply