🚀 Feature Request: Add a keep_routes configuration option

Describe the solution

An undocumented breaking change between wrangler 1 and wrangler 2 caused a global outage for us. Apparently in wrangler 2, routes are destructive. I saw in the docs how wrangler.toml is the source of truth for vars, but did not see anything in regards to routes.

Our deployment uses SSL for SaaS and we use the API to add routes to our worker. This use case is not covered by wrangler 2. Apparently omitting the route(s) key from wrangler.toml will prevent the destruction of existing routes, but I think it would be better to add an explicit option similar to keep_vars called keep_routes. This way our default route can remain in our wrangler.toml and we can add routes via API without worrying about them being deleted by an update.

[penalosa]

We definitely want to encourage people to update their workers via either Wrangler or the dashboard (and by extension the API), and not both. Updating a worker from two places leads to issues around where the source of truth is for an application-development teams will generally expect values that they set in wrangler.toml (and store in version control with history etc…) to be reflective of what’s deployed to Cloudflare, but modifying values through the API as well as from wrangler leads to situations where that’s not the case (in your case, that would be intentional, but it’s often a source of confusion). We don’t have any plans to disable editing via the dashboard at this stage, and modifying workers via the API is a core part of the workers platform that won’t be going away.

There are a couple of different paths forward here (as @JacobMGEvans noted, Wrangler 1 will be depreciated in the near future):

1. We could add a keep_routes option, as you’ve suggested. This is an option we’d prefer not to take, as it would mean we’d have to add keep_* options for bindings etc… as well, and would go against the idea of Wrangler (through wrangler.toml) being the source of truth for your application.

2. You could utilise a */* wildcard route with a gateway worker. In terms of which channel you’d dispatch to, KV is an option for that. Latency might not be that significant a concern, but could be something to measure-I’m not fully sure (my instinct would be that lookup would be pretty fast for these frequently accessed values). One benefit here is that it’d be easier to manage (I think) than your current solution-I don’t know how you’d do a zero-downtime promotion from canary to stable purely using the routes API, for instance.

3. We implement something similar to a keep_routes logic, but make it much more explicit what the trade offs are. As one idea, wrangler.toml could include a disable array, which could take routes, vars, etc…, which would have the effect of disabling those sections of the config file. I like the disabling idea, because it means that you can either have the route config in wrangler or set via the API, but not both at the same time.

I’d definitely suggest option 2 as the best one to move forward with. Another consideration here is that while there may not be a hard limit on the number of routes your account can have, there will be significant performance issues at scale.

[penalosa]

@SupremeTechnopriest I think our general suggestion for that would be to run a ‘gateway’ worker on the wildcard route, and delegate to the other workers from that via service bindings. If you could share more about your specific use case though, we could maybe provide more targeted advice.