Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: implement support for service bindings #906

Merged
merged 1 commit into from
May 17, 2022
Merged

Conversation

threepointone
Copy link
Contributor

@threepointone threepointone commented May 5, 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:

[[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:

export default {
  fetch(req, env, ctx) {
    return env.MYWORKER.fetch(new Request("./some-path"));
  },
};

Current critical drawbacks:

  • The api is a little buggy at the moment. We're investigating that internally.
  • It connects to, by default, the 'production' worker. If that has a KV or Durable Object or whatever, you could have data loss in production
  • Following which, say you run wrangler dev on two bound workers, then the requests do not go the development versions, and it's not obvious
  • No local mode support
  • Hard to test

Fixes #1026

@changeset-bot
Copy link

changeset-bot bot commented May 5, 2022

🦋 Changeset detected

Latest commit: afe7676

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package
Name Type
wrangler Patch

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

@github-actions
Copy link
Contributor

github-actions bot commented May 5, 2022

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-906

You 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-906

Or you can use npx with this latest build directly:

npx https://prerelease-registry.developers.workers.dev/runs/2337705327/npm-package-wrangler-906 dev path/to/script.js

@threepointone threepointone marked this pull request as draft May 5, 2022 19:03
@threepointone threepointone force-pushed the service-bindings branch 4 times, most recently from d6b0ee5 to b90f512 Compare May 12, 2022 10:02
@threepointone threepointone marked this pull request as ready for review May 13, 2022 14:58
@threepointone threepointone mentioned this pull request May 14, 2022
@threepointone threepointone force-pushed the service-bindings branch 3 times, most recently from 9ac761b to 66f07c5 Compare May 17, 2022 06:43
Copy link
Contributor

@petebacondarwin petebacondarwin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A bunch of NITs and suggestions. Nothing blocking landing this. Feel free to fix up and you see fit.

.changeset/hot-insects-cry.md Show resolved Hide resolved
.changeset/hot-insects-cry.md Outdated Show resolved Hide resolved
packages/wrangler/src/__tests__/configuration.test.ts Outdated Show resolved Hide resolved
packages/wrangler/src/config/environment.ts Show resolved Hide resolved
packages/wrangler/src/config/validation.ts Show resolved Hide resolved
packages/wrangler/src/index.tsx Outdated Show resolved Hide resolved
packages/wrangler/src/__tests__/dev.test.tsx Show resolved Hide resolved
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
@ghost
Copy link

ghost commented Jun 30, 2022

I can confirm the above syntax works however the one described in your documentation is not?
https://github.com/cloudflare/cloudflare-docs/blob/f3937ef122fd9b82220aeca8014e0c114fb4c3eb/content/workers/wrangler/configuration.md?plain=1#L217

I'm publishing my project using cloudflare/wrangler-action@2.0.0.

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
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

feat: implement support for service bindings
3 participants