Experimental support for incremental delivery (@defer/@stream) #6671
Assignees
Milestone
Comments
glasser
added a commit
that referenced
this issue
Sep 23, 2022
Requires a pre-release of graphql@17. More detailed commit message to come. Fixes #6671.
glasser
added a commit
that referenced
this issue
Sep 23, 2022
Requires a pre-release of graphql@17. More detailed commit message to come. Fixes #6671.
glasser
added a commit
that referenced
this issue
Sep 23, 2022
Requires a pre-release of graphql@17. More detailed commit message to come. Fixes #6671.
glasser
added a commit
that referenced
this issue
Sep 23, 2022
Also provides improved compatibility with the graphql-over-http spec by supporting `content-type: application/graphql-response+json` if requested via `accept` header, and adds `; charset=utf-8` to content-types. Executing `@defer` and `@stream` directives requires you to install pre-release of `graphql@17` in your server. This PR does not update `package.json` to install that prerelease (nor does it even broaden peer deps, which would be inadequate as many of its dependencies have peer deps that won't include v17). However, it does add a new CI step that installs a particular v17 pre-release and runs the test suite and smoke test (including running some otherwise-disabled tests that exercise the execution of these directives). We also add a new `__testing_incrementalExecutionResults` option that lets us test transport-level behavior without installing the prerelease. This change reworks `GraphQLResponse` and `HTTPGraphQLResponse` to allow responses to be single- or multi-part. `GraphQLResponse` had previously (in v4) moved most of its fields onto `result`; we now instead of `body` with two `kind`s determining the structure of the rest of the response. `HTTPGraphQLResponse` (new in v4) had tried to anticipate this change, but now the structure is a bit different. A few other changes were made for compatibility with `graphql@17` such as removing some uses of the non-options multi-argument GraphQLError constructor. Add two new plugin APIs: `didEncounterSubsequentErrors` and `willSendSubsequentPayload`. Updates to plugins: - Usage reporting waits until all payloads are ready before it's done with a given operation. - The response cache does not cache incremental responses (although that would likely be quite helpful). - No cache-control HTTP headers are written with incremental responses (since we don't know all the fields that will be executed yet). - Inline traces are not added to incremental delivery responses (though it might make sense to add them to the last payload or something). Fixes #6671.
glasser
added a commit
that referenced
this issue
Sep 23, 2022
Also provides improved compatibility with the graphql-over-http spec by supporting `content-type: application/graphql-response+json` if requested via `accept` header, and adds `; charset=utf-8` to content-types. Executing `@defer` and `@stream` directives requires you to install pre-release of `graphql@17` in your server. This PR does not update `package.json` to install that prerelease (nor does it even broaden peer deps, which would be inadequate as many of its dependencies have peer deps that won't include v17). However, it does add a new CI step that installs a particular v17 pre-release and runs the test suite and smoke test (including running some otherwise-disabled tests that exercise the execution of these directives). We also add a new `__testing_incrementalExecutionResults` option that lets us test transport-level behavior without installing the prerelease. This change reworks `GraphQLResponse` and `HTTPGraphQLResponse` to allow responses to be single- or multi-part. `GraphQLResponse` had previously (in v4) moved most of its fields onto `result`; we now instead of `body` with two `kind`s determining the structure of the rest of the response. `HTTPGraphQLResponse` (new in v4) had tried to anticipate this change, but now the structure is a bit different. A few other changes were made for compatibility with `graphql@17` such as removing some uses of the non-options multi-argument GraphQLError constructor. Add two new plugin APIs: `didEncounterSubsequentErrors` and `willSendSubsequentPayload`. Updates to plugins: - Usage reporting waits until all payloads are ready before it's done with a given operation. - The response cache does not cache incremental responses (although that would likely be quite helpful). - No cache-control HTTP headers are written with incremental responses (since we don't know all the fields that will be executed yet). - Inline traces are not added to incremental delivery responses (though it might make sense to add them to the last payload or something). Fixes #6671.
glasser
added a commit
that referenced
this issue
Sep 23, 2022
Also provides improved compatibility with the graphql-over-http spec by supporting `content-type: application/graphql-response+json` if requested via `accept` header, and adds `; charset=utf-8` to content-types. Executing `@defer` and `@stream` directives requires you to install pre-release of `graphql@17` in your server. This PR does not update `package.json` to install that prerelease (nor does it even broaden peer deps, which would be inadequate as many of its dependencies have peer deps that won't include v17). However, it does add a new CI step that installs a particular v17 pre-release and runs the test suite and smoke test (including running some otherwise-disabled tests that exercise the execution of these directives). We also add a new `__testing_incrementalExecutionResults` option that lets us test transport-level behavior without installing the prerelease. This change reworks `GraphQLResponse` and `HTTPGraphQLResponse` to allow responses to be single- or multi-part. `GraphQLResponse` had previously (in v4) moved most of its fields onto `result`; we now instead of `body` with two `kind`s determining the structure of the rest of the response. `HTTPGraphQLResponse` (new in v4) had tried to anticipate this change, but now the structure is a bit different. A few other changes were made for compatibility with `graphql@17` such as removing some uses of the non-options multi-argument GraphQLError constructor. Add two new plugin APIs: `didEncounterSubsequentErrors` and `willSendSubsequentPayload`. Updates to plugins: - Usage reporting waits until all payloads are ready before it's done with a given operation. - The response cache does not cache incremental responses (although that would likely be quite helpful). - No cache-control HTTP headers are written with incremental responses (since we don't know all the fields that will be executed yet). - Inline traces are not added to incremental delivery responses (though it might make sense to add them to the last payload or something). Fixes #6671.
glasser
added a commit
that referenced
this issue
Sep 23, 2022
…6827) Also provides improved compatibility with the graphql-over-http spec by supporting `content-type: application/graphql-response+json` if requested via `accept` header, and adds `; charset=utf-8` to content-types. Executing `@defer` and `@stream` directives requires you to install pre-release of `graphql@17` in your server. This PR does not update `package.json` to install that prerelease (nor does it even broaden peer deps, which would be inadequate as many of its dependencies have peer deps that won't include v17). However, it does add a new CI step that installs a particular v17 pre-release and runs the test suite and smoke test (including running some otherwise-disabled tests that exercise the execution of these directives). We also add a new `__testing_incrementalExecutionResults` option that lets us test transport-level behavior without installing the prerelease. This change reworks `GraphQLResponse` and `HTTPGraphQLResponse` to allow responses to be single- or multi-part. `GraphQLResponse` had previously (in v4) moved most of its fields onto `result`; we now instead of `body` with two `kind`s determining the structure of the rest of the response. `HTTPGraphQLResponse` (new in v4) had tried to anticipate this change, but now the structure is a bit different. A few other changes were made for compatibility with `graphql@17` such as removing some uses of the non-options multi-argument GraphQLError constructor. Add two new plugin APIs: `didEncounterSubsequentErrors` and `willSendSubsequentPayload`. Updates to plugins: - Usage reporting waits until all payloads are ready before it's done with a given operation. - The response cache does not cache incremental responses (although that would likely be quite helpful). - No cache-control HTTP headers are written with incremental responses (since we don't know all the fields that will be executed yet). - Inline traces are not added to incremental delivery responses (though it might make sense to add them to the last payload or something). Fixes #6671.
|
Fixed on version-4 |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
We'd like Apollo Server 4.0 to support incremental delivery (
@defer/@stream) if combined with a version ofgraphql-jsthat supports it. We expect this may impact the plugin API (as it will affect the shape of GraphQLResponse). We expect that we will describe this support as "experimental".The text was updated successfully, but these errors were encountered: