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.

Sign up for GitHub

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

Jump to bottom

indicate the supported defer specification version in Accept and Content-Type #1648

Closed
Tracked by #80
Geal opened this issue Aug 30, 2022 · 0 comments · Fixed by #1652
Closed
Tracked by #80

indicate the supported defer specification version in Accept and Content-Type #1648

Geal opened this issue Aug 30, 2022 · 0 comments · Fixed by #1652
Assignees
@Geal
Labels
component/defer

Comments

@Geal
Copy link
Contributor

Geal commented Aug 30, 2022 •
edited
Loading

Since the @defer specification is still in development, the clients and router should indicate which version they support:

  • the client sends a request with the header Accept: multipart/mixed; deferSpec=20220824, application/json
  • the router returns responses with the header Content-Type: multipart/mixed; boundary="graphql"; deferSpec=20220824
@abernix abernix added this to the v1.0.0-alpha.1 milestone Aug 30, 2022
@Geal Geal mentioned this issue Aug 30, 2022
Merged
Geal added a commit that referenced this issue Aug 31, 2022
@Geal @abernix
Pin the supported defer specification version to 20220824 (#1652)
8410179 
Fix #1648
Fix #1656
Fix #1659

Pinned to this commit:
graphql/graphql-spec@01d7b98

Since the router will ship before the `@defer` specification is done, we
add a parameter to the `Accept` and `Content-Type` headers to indicate
which specification version is accepted

Co-authored-by: Jesse Rosenberger <git@jro.cc>
This was referenced Sep 1, 2022
Closed
Closed
abernix added a commit that referenced this issue Sep 2, 2022
@abernix
Change default and promote experimental_defer_support to `preview_d…
1d88e3a 
…efer_support`

Following up on a tremendous amount of work tracked in
#80 - which brought various
stages of `@defer` support to the Router - this changes our designation of
its status from "Experimental" to "Preview".  It's worth noting that the
specification *just* graduated to "Stage 2 (Draft)" mode in the GraphQL
Working Group, so changes may still be expected and there are two stages
ahead.  To help things progress we've:

- We've lifted the previous requirement that users opt into defer support by
  setting `experimental_defer_support: true` in the `server` section of their
  configuration.  It is now on by default.
- The option is now called `preview_defer_support` and it can be set to
  `false` to _specifically_ opt out of it existing at all.  This might be
  desired if you would prefer that it not even show up in introspection or
  be possible to use even if a client requests it.
- Using `@defer` support _requires_ clients set the appropriate HTTP
  `accept` header to use it.  This puts the burden of understanding the
  risks of an early-preview on the clients who will need to consume the
  Router's responses. This is particularly important for clients who have
  long-lived support requirements (like native mobile apps).

  To see which headers are required, see #1648.

Closes #1673
This was referenced Sep 2, 2022
Merged
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@Geal Geal

Labels
component/defer
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Pin the supported defer specification version to 20220824 apollographql/router
2 participants
@Geal @abernix