Support `disabled` routes in Wrangler configuration

[captain-kark]

💡 Feature request

Support for workers which, when configured and "published" via wrangler, appear as "Disabled" in the UI.

Overview and problem statement

I would like to include additional configuration for workers which operate on routes that have a very broad scope, such as mysite.com/api/* to manage specific routes which I know do not need to invoke not just the current worker, but any worker, in order to reduce unnecessary worker invocations.

Basic example

Currently, I must do this manually, or automate it via some light scripting. Although it's not that bad to manage this via the API, it'd be much nicer to get this type of feature in front of users so that it can reduce worker invocations.

It would be great to set this in my wrangler.toml file somehow, perhaps as an "environment".

wrangler.toml

type = "webpack"
account_id = "..."
zone_id = "..."
name = "all-i-want-for-christmas-is-fetch-event-bubbling"
route = "mysite.com/api/*"

[env.disabled]
type = "disabled"
routes = ["mysite.com/api/.well-known/jwks", "mysite.com/api/customers/thatoneguy/*", "mysite.com/api/externalthing/*" ]

$: wrangler publish -e disabled

Or however you want to do it. The important part is that this information about disabled routes is contained next to the rest of my worker's source code. The bits where workers aren't running is just as important as where they do run!

[ObsidianMinor]

Perhaps this could be done with a route object, so you could enter an enabled string or an inline table with a disable bool. For example

routes = [
    "mysite.com/api/*",
    { disable = true, route = "mysite.com/api/.well-known/jwks" },
    { disable = true, route = "mysite.com/api/customers/thatoneguy/*" },
    { disable = true, route = "mysite.com/api/externalthing/*" },
]

[tbgse]

This would be fantastic to have, keeping track of disabled routes and keeping them consistent (especially with multiple environments) is a big challenge for us. Is this something that might make it on the roadmap?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity in the last 180 days. It will be closed if no further activity occurs in the next week. Please feel free to comment if you'd like it to remain open, and thank you for your contributions.

[h3ku]

Any updates on this?

[petebacondarwin]

Transferring to the Wrangler 2 repo for triage and prioritisation.

[tbgse]

@petebacondarwin so happy to see this in the wrangler 2 repo, do you have any idea when / if this feature might be picked up? This is one of our biggest pain points right now working with wrangler since we have to manually set a lot of disabled routes through the cloudflare UI, which consumes a lot of time and is a very error prone process. Would really appreciate an update 🙏

[threepointone]

This will be a significant amount of work on the dashboard, so I can't be sure when it'll be prioritised. But I'm happy to discuss alternatives on the wrangler side. How would you feel if we went with @ObsidianMinor's suggestion, and we could optionally mark a route as disabled with the object syntax/form?

[tbgse]

Yes, the proposed solution by @ObsidianMinor to configure routes in the wrangler config file is exactly what we're looking for. It'd make our life so much easier.

[threepointone]

I'll discuss this internally and we'll get back to this issue.

[nathansf]

Any updates on this? This would be a very useful feature for us since we're currently managing many routes for which services are disabled, and would prefer to track changes via wrangler.toml history.

[threepointone]

I don't really work here anymore, but I think this should the key code change for it If someone could pick this up and add tests/types, I think it should work?

(alternately, have you tried just commenting out the routes in wrangler.toml?)

[threepointone]

dammit I think it should be reading from config.routes, not props.routes

[penalosa]

Unfortunately I think this is slightly more involved (there's an API endpoint for disabling workers on a route, so I imagine we'd want to hit that). It's in the backlog though, and we'll definitely get to it (not sure on a timeline yet though)

[GeKorm]

Is it yet time for the yearly update on this issue? 🙂

[fernandopasik]

Could it be that the disabled on this route feature is controversial because wrangler.toml files configure a specific worker and we are trying to affect something about the route and not the worker? Don't get me wrong, I'd love to have this as a feature

[admah]

@fernandopasik you're right - we do want keep wrangler.toml for configuring a Worker and related resources, not larger account-level things like routes.

Can you help me understand this feature request a bit more? How is this better than the current dashboard experience? Is this for actually configuring disabled routes or is it more of a record-keeping/documentation issue?

[oritwoen]

@admah I will give you context using the example of a real application that I have been working with on Cloudflare for several years.

I have the frontend of a very large website built on Nuxt 3 and its backend on WordPress. Thanks to Cloudflare Workers, I was able to do seamless headless integration without putting up new infrastructure or servers - it's wonderful.

My wrangler.toml file looks like this:

name = "website"
main = "./.output/server/index.mjs"
account_id = "xxx"
workers_dev = false
compatibility_date = "2023-08-31"

[site]
bucket = ".output/public"

[placement]
mode = "smart"

[env.development]
routes = [ { pattern = "dev.mysite.com/*", zone_name = "mysite.com" } ]

[env.production]
routes = [ { pattern = "mysite.com/*", zone_name = "mysite.com" } ]

[env.development.vars]
GQL_HOST = "https://dev.mysite.com/graphql"
NUXT_PUBLIC_API_HOST = "https://dev.mysite.com"

[env.production.vars]
GQL_HOST = "https://mysite.com/graphql"
NUXT_PUBLIC_API_HOST = "https://mysite.com"

However, Worker Routes in the panel as in the screenshot below.

Thanks to this, I can maintain both WordPress and Frontend Nuxt 3 on the same domain at the same time without any problems, without any proxies, combinations or advanced infrastructures. The problem is that with the increasing number of URLs in the backend and several environments, as well as the non-intuitive UI, everything gets confusing and sometimes I make mistakes and managing it is inconvenient.

For these types of headless systems, it should be possible to configure them using a single file instead of having to move around to different places, which increases the risk of error and security.

[penalosa]

@oritwoen for your use case, we'd usually recommend running the worker on /* (as you have it) and then calling fetch(request) within the worker to fallthrough to the origin when necessary. This should be easier to manage than setting up explicit disabled routes in the dashboard. Would that work for your use case?

[oritwoen]

@penalosa this is a bit unclear to me. Could you please show an example or documentation link - something that would visualize your solution?

[fujohnwang]

@oritwoen for your use case, we'd usually recommend running the worker on /* (as you have it) and then calling fetch(request) within the worker to fallthrough to the origin when necessary. This should be easier to manage than setting up explicit disabled routes in the dashboard. Would that work for your use case?

That will introduce more round trips for each requests.

I have same issue with a gateway worker and backend services.

at first, I let gateway worker intercept everything, but customers and I feel it's too slow at each request, but the back is just SSG site.

so I have to cherry pick multiple route patters as per the application and site paths, and put the configuration in wrangler.toml AND dash web console.

If there is a way to define all routes in wrangler.toml, then I don't have to configure route patterns in two different places.

I play a trial-and-error, but found it not work with wrangler.toml only, since it has limits on just custom_domain and zone_id/_name.

The following configuration content is what I prefer:

routes = [ { pattern = "dev.mysite.com/*", zone_name = "none|NONE" } ]