feat: implement support for service bindings #906
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
🦋 Changeset detectedLatest commit: afe7676 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
A wrangler prerelease is available for testing. You can install this latest build in your project with: npm install --save-dev https://prerelease-registry.developers.workers.dev/runs/2337705327/npm-package-wrangler-906You can reference the automatically updated head of this PR with: npm install --save-dev https://prerelease-registry.developers.workers.dev/prs/906/npm-package-wrangler-906Or you can use npx https://prerelease-registry.developers.workers.dev/runs/2337705327/npm-package-wrangler-906 dev path/to/script.js |
threepointone
force-pushed
the
service-bindings
branch
4 times, most recently
from
d6b0ee5 to
b90f512
Compare
threepointone
force-pushed
the
service-bindings
branch
from
b90f512 to
6ffc650
Compare
Closed
threepointone
force-pushed
the
service-bindings
branch
3 times, most recently
from
9ac761b to
66f07c5
Compare
petebacondarwin
approved these changes
May 17, 2022
This adds experimental support for service bindings, aka worker-to-worker bindings. It's lets you "call" a worker from another worker, without incurring any network cost, and (ideally) with much less latency. To use it, define a `[services]` field in `wrangler.toml`, which is a map of bindings to worker names (and environment). Let's say you already have a worker named "my-worker" deployed. In another worker's configuration, you can create a service binding to it like so:
```toml
[[services]]
binding = "MYWORKER"
service = "my-worker"
environment = "production" # optional, defaults to the worker's `default_environment` for now
```
And in your worker, you can call it like so:
```js
export default {
fetch(req, env, ctx) {
return env.MYWORKER.fetch(new Request("http://domain/some-path"));
},
};
```
Fixes #1026
threepointone
force-pushed
the
service-bindings
branch
from
66f07c5 to
afe7676
Compare
Merged
|
I can confirm the above syntax works however the one described in your documentation is not? I'm publishing my project using cloudflare/[email protected]. |
1 task
jrencz
added a commit
to jrencz/miniflare
that referenced
this pull request
Jul 3, 2022
I noticed that in Workers docs and Miniflare there's inconsistency in how services are declared: - Workers expect `binding` key https://github.com/cloudflare/cloudflare-docs/blob/a65a35843ffb7b69caf2758cc5f2ad805251d166/content/workers/wrangler/configuration.md?plain=1#L212-L220 - Miniflare expects `name` I added 2 graceful and 2 error scenarios: - (graceful) accept `name` with warning if `binding` is missing - (graceful) accept `name` and `binding` both given and the same - (error) throw if both `binding` and `name` are given but they don't match - (error) throw if neither `binding` not `name` is given I decided to handle it with errors, not with mutually exclusive presence of either `name` or `binding` in interface `WranglerServiceConfig` because `name` should go away - it's just a behavior mismatch. Related: cloudflare#280 Syntax in wrangler2: cloudflare/workers-sdk#906
mrbbot
pushed a commit
to cloudflare/miniflare
that referenced
this pull request
Jul 9, 2022
) * Allow helper `parsePluginWranglerConfig` to be given `Log` instances * Fix inconsistency: services have `binding` not `name` in `wrangler.toml` I noticed that in Workers docs and Miniflare there's inconsistency in how services are declared: - Workers expect `binding` key https://github.com/cloudflare/cloudflare-docs/blob/a65a35843ffb7b69caf2758cc5f2ad805251d166/content/workers/wrangler/configuration.md?plain=1#L212-L220 - Miniflare expects `name` I added 2 graceful and 2 error scenarios: - (graceful) accept `name` with warning if `binding` is missing - (graceful) accept `name` and `binding` both given and the same - (error) throw if both `binding` and `name` are given but they don't match - (error) throw if neither `binding` not `name` is given I decided to handle it with errors, not with mutually exclusive presence of either `name` or `binding` in interface `WranglerServiceConfig` because `name` should go away - it's just a behavior mismatch. Related: #280 Syntax in wrangler2: cloudflare/workers-sdk#906
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This adds experimental support for service bindings, aka worker-to-worker bindings. It's lets you "call" a worker from another worker, without incurring any network cost, and (ideally) with much less latency. To use it, define a
[services]field inwrangler.toml, which is a map of bindings to worker names (and environment). Let's say you already have a worker named "my-worker" deployed. In another worker's configuration, you can create a service binding to it like so:And in your worker, you can call it like so:
Current critical drawbacks:
Fixes #1026