[Workers] Multi Workers development #23122
Conversation
|
Howdy and thanks for contributing to our repo. The Cloudflare team reviews new, external PRs within two (2) weeks. If it's been two weeks or longer without any movement, please tag the PR Assignees in a comment. We review internal PRs within 1 week. If it's something urgent or has been sitting without a comment, start a thread in the Developer Docs space internally. PR Change SummaryAdded a comprehensive guide on developing with multiple Workers, detailing various approaches and configurations.
Added Files
How can I customize these reviews?Check out the Hyperlint AI Reviewer docs for more information on how to customize the review. If you just want to ignore it on this PR, you can add the Note specifically for link checks, we only check the first 30 links in a file and we cache the results for several hours (for instance, if you just added a page, you might experience this). Our recommendation is to add |
|
This pull request requires reviews from CODEOWNERS as it changes files that match the following patterns:
|
|
Preview URL: https://7b7b7a53.preview.developers.cloudflare.com Files with changes (up to 15) |
edmundhung
force-pushed
the
edmundhung/multi-workers-development
branch
3 times, most recently
from
67adec5 to
7ca0616
Compare
edmundhung
requested review from
GregBrimble,
irvinebroque,
mikenomitch,
korinne,
WalshyDev,
kodster28 and
a team
as code owners
edmundhung
force-pushed
the
edmundhung/multi-workers-development
branch
2 times, most recently
from
9c8216b to
fde2029
Compare
|
|
||
| - Workers are closely related or part of the same application | ||
| - You want the simplest development setup | ||
| - You need to access a Durable Object namespace from another Worker using `script_name` |
There was a problem hiding this comment.
I wonder if we should have a "limitations" section?
|
|
||
| Use this approach when: | ||
|
|
||
| - Each Worker uses a different build configuration |
There was a problem hiding this comment.
Does this mean Vite vs Wrangler?
|
|
||
| - Workers are closely related or part of the same application | ||
| - You want the simplest development setup | ||
| - You need to access a Durable Object namespace from another Worker using `script_name` |
There was a problem hiding this comment.
| - You need to access a Durable Object namespace from another Worker using `script_name` | |
| - You want to use RPC to a Durable Object namespace from another Worker (i.e. using `script_name`) |
| - Different teams maintain the Workers | ||
| - A Worker only occasionally accesses another, and you prefer the flexibility to run them separately |
There was a problem hiding this comment.
i don't really see why these are necessarily the case? it seems pretty reasonable to me to run all workers in one dev session for the last two points here.
There was a problem hiding this comment.
I updated the wording to clarify it better. Hope this helps.
| - Workers are closely related or part of the same application | ||
| - You want the simplest development setup | ||
| - You need to access a Durable Object namespace from another Worker using `script_name` | ||
|
|
There was a problem hiding this comment.
also maybe mention if one of your projects is pages, and you also have some workers alongside, you can use wranlger pages with multiple configs
There was a problem hiding this comment.
I am not sure if we should include Pages here as this is under the Worker docs 🤔
| Use this approach when: | ||
|
|
||
| - You have an independent Worker that is shared across multiple applications | ||
| - You are integrating with a legacy Worker that you don't want to refactor yet |
There was a problem hiding this comment.
i don't think any of these points necessarily mean you have to do this - afaict, the only reason is if you want to use vite for some but not all workers?
There was a problem hiding this comment.
Right. It's fine for people to use either wrangler or vite. This is more about having a legacy Worker in a different setup that your main Worker. Updated the wording to reflect that better.
|
|
||
| - Workers are closely related or part of the same application | ||
| - You want the simplest development setup | ||
| - You need to access a Durable Object namespace from another Worker using `script_name` |
There was a problem hiding this comment.
i think queues with separate producer/consumers requires this set up too: https://developers.cloudflare.com/queues/configuration/local-development/#separating-producer--consumer-workers
There was a problem hiding this comment.
Good call! Added this to the simple command section.
|
should we link to the vitest section on multiple workers too? and also something about type gen |
|
There's something about this explanation (screenshot below) that made it hard for me to understand that this boils down to basically: "To run multiple Workers from one local dev session, for each Worker, add npx wrangler dev -c wrangler.jsonc -c ../api/wrangler.jsoncThe first <then, after saying this, show the example> 
|
edmundhung
force-pushed
the
edmundhung/multi-workers-development
branch
2 times, most recently
from
0fc5134 to
c48df1d
Compare
I think this guide is better focus on the different approaches we offered and when to use them, which doesn't matter with vitest / type gen.
I removed to example wrangler config to focus on the dev commands and vite config required. |
edmundhung
force-pushed
the
edmundhung/multi-workers-development
branch
2 times, most recently
from
43a73c3 to
f3acf66
Compare
edmundhung
force-pushed
the
edmundhung/multi-workers-development
branch
from
f3acf66 to
7b7b7a5
Compare
Summary
This adds a Multi Worker development guide under Development & testing to showcase the different approaches to run multiple Workers locally and when to use each approach.
Screenshots (optional)
Documentation checklist