Should `--local` be the default?

Now that we have an officially supported “local” development environment, the question begs to be asked - should local mode be the default when you start up? There are plenty of positives -

• You don’t have to login to start developing
• It starts ‘instantly’ (relatively speaking of course)
• In watch mode, it refreshes ‘instantly’
• It’ll ‘work’ automatically in environments like codespaces/csb/etc (excluding devtools etc)

There are drawbacks too, of course -

• Given the chance of implementation drift between miniflare and cloudflare, you want to make sure your code works in production as your developed it, and you maaay miss something in local mode.
• This is exacerbated by things like compatibility_date and compatibility_flags
• It’ll be breaking behaviour from wrangler v1 for commands like kv:namespace, kv:key etc etc, so it may confuse someone who runs the commands and sees nothing happens on their actual production sites

I don’t think the drawbacks outweight the positives, but I’d like to put the idea out there for a while, and get feedback before we commit to it. Of course, you will always be able to use both local and, er, ‘remote’ mode, it’s just a question of what the default starting experience should be.

[WalshyDev]

Personally, I would like to default to local. Being able to configure Miniflare to persistent (or not persist) things like KV and DO data is fantastic. It picking up on .env and more. It’s also just generally much quicker to develop with Miniflare in my opinion and my workflow very much depends on it these days.

There are of course the downsides, for example working with DOs was a pain for quite a while there with Miniflare. Hopefully this drift of implementation and mock is smaller now that Miniflare is official.

It’s also super nice sometimes to have code running on the edge before production just to verify that it does indeed work and there’s no weirdness with Miniflare. That’s when I actually use edge-dev is to make sure things work before a production push. This would be an option either way though and I do not mind specifying --edge for when I actually do use this.

In my opinion, Miniflare being default makes a lot of sense.

[irvinebroque]

Live debugging in dev, with code running on a real Cloudflare Worker, is a killer feature." Could you explain why this is so critical?

Yep - I know from talking to others that my view isn’t consensus, but here’s why I think this is the case:

1. Dev environment matching production 1:1 prevents inconsistencies between the two as the source of bugs. No other modern platform (AFAIK) lets you run code in dev on the literal exact runtime/instance/etc. as production. I think this gets increasingly important with Workers KV, Durable Objects, and any other stateful products built on top of these primitives, and I would explicitly distrust any local shim implementation of these services. Consider a common source of bugs with current production applications at scale - locally in dev, engineers run a local MySQL instance, everything seems like it works, but then when their code runs in production, it’s running against a sharded set of Aurora instances fronted by Proxy SQL, ELBs, etc… Same APIs, but different infrastructure = subtle differences with transaction behavior, etc. I’m sure the current Miniflare implementations of KV/Durable Objects are really excellent, but why not eliminate the surface area altogether? The issues in the node community with Jest and JSDom are IMO instructive examples of the risks of layers of software being built on top of mock implementations. The magic of workers is that we can use the real thing and avoid all of this!
2. Dev running on workers === easier custom domains in dev, sharable links without localhost. See cloudflare/wrangler2#696 - anyone building apps that depend on incoming webhooks needs to expose their dev environment at a public URL. If my requests in dev already have to be proxied by ngrok (or cloudflared), why not run on workers instead of localhost? What is localhost giving me, other than a potential source of headaches (for me and for maintaining wrangler). My understanding is that under the hood wrangler dev already spins up a subdomain, and then tunnels it back to localhost via cloudflared, but what I’d want is to just access that public domain directly, and be able to configure it and count on it being static.
3. Run on a real Worker in dev === use future prod debugging/logging/analytics features in dev. Cloudflare has great built-in tools on the dashboard, with surely lots more on the way. Ex: I can look at my worker’s P95 CPU timing on the workers dashboard, look at cache analytics for my domain, request geo routing, etc. This is all stuff that’s not always easy to do in dev, and way out of scope for wrangler to provide, beyond wrangler tail. But it doesn’t seem crazy to provide these types of tools in development if the code is already running on the same Worker runtime as production. You could do stuff like “visualize a request path through a worker” without having to build anything new into wrangler itself. I think there’s tons of greenfield space here to go after “changes that today can only be tested by pushing a change to production”. Maybe preview deployments are really where that comes in, but why not shorten the feedback loop even further and put it in dev?

I know the big tradeoff with all of this (today) is local frontend developer experience - hot reloading magic, instant as-you-type editing are hard to implement with wrangler syncing files to a worker. I love this stuff, it’s what got me excited about frontend and React ~8 years ago! But I will happily trade that 10/10 times for a dev environment that mirrors production 1:1. Saving hours caused by bugs in prod or chasing down dev/prod inconsistencies > saving ms hot reloading. Dev environments that mirror production will help convince a whole engineering team to move to Workers, not just the frontend nerds who are excited about the edge.