feat: implement support for service bindings #1026
Assignees
Labels
enhancement
New feature or request
Comments
threepointone
pushed a commit
that referenced
this issue
May 16, 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("./some-path"));
},
};
```
Fixes #1026
threepointone
pushed a commit
that referenced
this issue
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("./some-path"));
},
};
```
Fixes #1026
threepointone
pushed a commit
that referenced
this issue
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("./some-path"));
},
};
```
Fixes #1026
threepointone
pushed a commit
that referenced
this issue
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
added a commit
that referenced
this issue
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
Co-authored-by: Daniel Rivas <[email protected]>
Repository owner
moved this from In Review
to Done
in workers-sdk
May 17, 2022
Merged
|
Hi! I want to call out that this API remains undocumented at api.cloudflare.com, which is ostensibly blocking my PR to cloudflare-go: cloudflare/cloudflare-go#849 Would greatly appreciate API docs for use cases where a customer is not using wrangler. |
|
Hi! I'll route your request to the team, we're not directly in charge of that. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
As announced in https://blog.cloudflare.com/service-bindings-ga/, this issue tracks first class integration in wrangler.
The text was updated successfully, but these errors were encountered: