If you're using auxiliaryWorkers in @cloudflare/vite-plugin, we want to know why

[jamesopstad]

Hi all. We are working on version 2 of the Cloudflare Vite plugin. As part of this we are evaluating the existing feature set.

There are currently two ways to develop with multiple Workers when using the Vite plugin.

1. Using the dev registry

This is a feature that works automatically to enable multiple vite dev sessions to connect to each other.

2. Using auxiliaryWorkers

This is a feature that enables running multiple Workers with a single vite dev command. These Workers are also built together when running vite build.

When v1 was introduced there were several features that were possible with auxiliaryWorkers that were not possible with the dev registry. These included calling a Durable Object or Workflow directly from another Worker. These feature gaps have now been closed and so should no longer be determining factors in which method you choose.

If you are currently using auxiliaryWorkers, we want to know why. We are particularly interested in what you are using it for and whether it would fit your use case to use the dev registry. Thanks!

[jahands]

I use it so that I can vite dev in a Worker that talks to a Durable Object owned by another Worker:

[fforres]

TL;DR: Auxiliary workers helped us have an explicit dependency graph. For us this question is more ergonomics issue than anything else. I like auxiliary workers more, agents benefit from having to deal with less implicit/magical BS. Tradeoff... it's using a loot of memory in our machines.

(PS: Removing them would suck make monorepo management/optimizations on Cloudflare super hard.)

---

For context, We have a decently sized monorepo ATM. Part of it is our CF Worker infra. (~20 workers with staging, prod & dev variants, so ~60. total). Used to have one big API and now we've separated functionality in smaller services with one worker as our gateway API doing authentication checks/etc. Services don't have public network access and are either accessible publicly through the gateway or as bindings to other services. (pretty normal multi-services approach).

Unless I'm mistaken on the dev registry, I assume it's mapping what services Am I manually running and routing things correctly for me. And if so, Well it is useful once an architecture start scaling we can really use an explicit service dependency tree.

For us, our decision to split into multiple services was driven by the single worker that we had for API being really big and falling into startup time and bundle size blockers. (We could not deploy because startup time was over X ms, also for some time we could not ship maps, because we were over the amount of megabytes).

Initially our split was very functionality based, 3 main workers:

• "API" - rest api, some trpc endpoints.
• "Agents" - which was a single worker exposing a bunch of DurableObjects/agents.
• "Workflows" - single worker exposing all of our Workflows.
  And we had bindings to use them in between them.

The more we grew, the more that that stopped making sense and we started to move to a more product domain-based approach. Imagine a users-worker. It exposes some agents/durable objects, a couple of workflows, a cron, and either RPCs for the API-gateway to use/expose, and a request paths to delegate the api-gateway request).

Benefits of this?
Super small domains, I don't need to load 10MBs of JS just to send an email. Request stay fast, (We don't spend as much money per request), I don't need to ship the world on every commit, and agents have a clearer picture of 'what goes where' when working on our monorepo.

(We made a bet in 2023 that while monorepo management still sucks... in an post-AI world they will be the bomb. And here we are)

Back to my initial paragraph, GatewayAPI uses ~15 workers underneath (not all direct aux workers).
Going to 15 terminals to run your dev env sucks (sure you can have scripts for this but then output consolidation sucks). Also, Autonomous agents working on a PR will have the same problem of 'remembering' to lift 15 services. Sure, you can argue "Adding it to agents.md solves this"... I'd counter-argue as to why should it? What if this was not a problem to begin this.
Something like the dev registry also gets weird when we are Orchestrating different runs of services with worktrees.

---

So for our architecture, this is more a problem of explicit v/s implicit definition, and explicit dependency tree definition wins.

On the infra side, An explicit dependency tree allows us to decide what tests to run in CI.
If the 'payment' service changes, I want to run the API test suite, but i don't care about the 'database' test suite so i don't run it.

Also it helps us decide what things to actually deploy as preview environment. Same example I can deploy a preview environment of API pointing to the preview environment of payment while all of the other bindings still point to staging.

On the AI side, an agent now knows what affects what, can decide what tests and checks to run, checks are now quicker, which that help it course correct faster, do less context pollution and be better at autonomous work.

In short, the dev registry great for small projects but In our experience, it has not been viable as we grow.

---

My only wish would be that I can have some deferred loading for auxiliaryWorkers 🙏🏼 (or reduce memory footprint?) Right now running more than a handful of workers does use a decent chunk of memory.

Continuing with the payment workers analogy: I ONLY need the payments worker (Which could load a bunch of SDKs for stripe and shopify and other vendors etc), when I'm actually hitting a /payment request, or calling an RPC to run a payment workflow. If that is not something that I usually test locally... Why would I load it beforehand? But also don't want my request to crash if i forgot run the service manually.... I Haven't explored this part but wondering if we'd be able to expose some proxy in the bindings to detect when a specific worker is being accessed and the vite run till that happens)