-
Notifications
You must be signed in to change notification settings - Fork 2k
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
execute: integrate subscriptions and refactor pipeline #3644
Conversation
✅ Deploy Preview for compassionate-pike-271cb3 ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
Hi @yaacovCR, I'm @github-actions bot happy to help you with this PR 👋 Supported commandsPlease post this commands in separate comments and only one per comment:
|
ce28d68
to
dc3b18d
Compare
393bdfc
to
eaf786d
Compare
cbd99b5
to
6946681
Compare
a198622
to
f18583f
Compare
The `execute`/`executeImpl` and `createSourceEventStream`/`createSourceEventStreamImpl` functions follow the same basic pattern of building the contet and using it to run a function. This PR extracts that pattern into a separate function. For good measure, the same pattern in applied to the soon-to-be-deprecated `subscribe` function. Hheavier refactoring is on the way from @IvanGoncharov (see graphql#3639 (review)), but in the meantime, this consolidates the common pattern without any breaking changes.
...to executeSubscriptionRootField => because that's what it does!
...because that's what it does! The execution of an operation returns a map of data/errors, not just the data.
`execute` no longer runs the query algorithm for subscription operations. Rather, subscription operations are performed, as per the spec. `subscribe` is deprecated.
to replace the old exported functionality from execute
f18583f
to
9fc1d93
Compare
separates internal errors array from the remainder of the Execution data. obviates the need for the buildPerEventExecutionContext function => as described by the spec, all execution info is the same for execution of subscription events except for the root value, which is set as the payload the separate executionContext variable introduced is similar to the payloadContext that will be necessary to support defer/stream
Advanced clients setting up services that only process subscriptions should be encouraged to create a custom ExecutionInfo object and use the corresponding internal functions that take ExecutionInfo objects rather than raw arguments. These functions are currently createSourceEventStreamImpl and executeQuery but when createSourceEventStream is removed, reateSourceEventStreamImpl will be renamed to createSourceEventStream
in favor of the corresponding functions that take ExecutionInfo arguments, i.e. createSourceEventStreamImpl and executeQuery. Note that since createSourceEventStream has been removed, createSourceEventStreamImpl can be renamed to createSourceEventStream, so that the recommended function name has not in fact changed, buf the function now takes an ExecutionInfo argument
Now that #3658 suggests that we may be awaiting a serious refactor, this PR has been reworked to represent a least change approach to the existing API. Rather than list the individual steps to the granularity of every renamed function, I will just list broadly what the PR accomplishes, after which I will list what the PR does not do.
What this PR does not do:
|
The new |
Ah => I forgot to mention that I have also snuck in here a new argument to allow total customization of the executor used by EXECUTE_SUBSCRIPTION_EVENT. As well as a default executor: export const defaultSubscriptionEventExecutor = (
exeInfo: ExecutionInfo,
payload: unknown,
): PromiseOrValue<ExecutionResult> =>
executeQuery({
...exeInfo,
rootValue: payload,
}); This workflow allows the |
Closing this for now in favor of plan in #4210 |
to safely export buildExecutionContext() as validateExecutionArgs() motivation: this will allow us to: 1. export `executeOperation()` and `executeSubscription()` for those who would like to use directly. 2. add a `perEventExecutor` option to `ExecutionArgs` that allows one to pass a custom context for execution of each execution event, with the opportunity to clean up the context on return, a la #2485 and #3071, addressing #894, which would not require re-coercion of variables. The signature of the `perEventExecutor` option would be: ```ts type SubscriptionEventExecutor = ( validatedExecutionArgs: ValidatedExecutionArgs): PromiseOrValue<ExecutionResult> ``` rather than: ```ts type SubscriptionEventExecutor = ( executionArgs: ExecutionArgs): PromiseOrValue<ExecutionResult> ``` This might be a first step to integrating `subscribe()` completely into `execute()` (see: #3644) but is also a reasonable stopping place.
to safely export buildExecutionContext() as validateExecutionArgs() motivation: this will allow us to: 1. export `executeOperation()` and `executeSubscription()` for those who would like to use directly. 2. add a `perEventExecutor` option to `ExecutionArgs` that allows one to pass a custom context for execution of each execution event, with the opportunity to clean up the context on return, a la #2485 and #3071, addressing #894, which would not require re-coercion of variables. The signature of the `perEventExecutor` option would be: ```ts type SubscriptionEventExecutor = ( validatedExecutionArgs: ValidatedExecutionArgs): PromiseOrValue<ExecutionResult> ``` rather than: ```ts type SubscriptionEventExecutor = ( executionArgs: ExecutionArgs): PromiseOrValue<ExecutionResult> ``` This might be a first step to integrating `subscribe()` completely into `execute()` (see: graphql/graphql-js#3644) but is also a reasonable stopping place.
execute
no longer runs the query algorithm for subscription operations. Rather, subscription operations are performed, as per the spec.subscribe
andcreateSourceEventStream
are removed.See additional comments below.