Update experimental `@defer` support to meet latest accepted spec

[kodai3]

While I was trying Apollo Client's experimental support for defer, I find graphql-js v17.0.0-alpha.3(latest alpha) is not work with latest Apollo Client.

Because , as of that version, response result type of incremental value is changed and Apollo Client still expect path field and fails here

As @bignimbus mentioned on X, we do need to come up with solid way to support each spec updates.

In my opinion, since both graphql-js and Apollo Client are clearly in experimental state, backport is not always necessary

[bignimbus]

Hi @kodai3, just to be clear I did not say we should support each draft iteration, only that a conversation could be started about it. Happy to let that conversation happen but with the right context set. Thanks!

[kodai3]

Thank you for clarifying.

I'm sorry for misleading (I'm learning English as non-native).
I realized the choice of words is poor reading back🥲

I know we don't need to support each and every update.
The documentation of which iteration the experimental support is currently targeted. I think this could work as well.

It took me some time to figure out the problem and find no existing discussion around there.
Basically that's what I want to improve here.

[bignimbus]

Responding to @jakobkhansen's comment in the linked issue:

When we started supporting @defer we made a decision to pin our support on the version of the draft spec that was valid as of 2022-08-24. Even though that proposal is in Stage 3, the last stop before acceptance into the spec, the incremental transport format has changed a lot in the working draft spec since that time. This presents a challenge for JavaScript clients in particular, where every byte counts. So when servers ship new versions of the incremental transport protocol, we are faced with the design decision of breaking backwards compatibility or introducing conditional logic, which might add bloat to the library. As I understand it, the Apollo Server implementation should be working off that same spec version as Apollo Client supports, but it appears we need to investigate that further, so thanks for bringing it to our attention!

As it stands today, the team was not planning on adding support for additional iterations of the draft spec but will absolutely support the accepted version of the spec when that happens. But we'd like to keep this issue open for the community's feedback and learn more about use cases that we could consider supporting in the meantime.

[thomaswelton]

Just noting here that I've submitted a PR to update the docs to state which alpha version of graphql Apollo is compatible with apollographql/apollo-server#7834

[Maxou44]

Any news about an Apollo Client update to support the Alpha 3 ?

[jerelmiller]

Hey @Maxou44 👋

We are still waiting for the spec to stabilize before we add support for the newer format since there are still multiple formats being considered (see graphql/graphql-spec#1077 and graphql/graphql-spec#1074). We'd like to avoid confusion/bundle size while we are still unsure what the final format will be.