search

apollographql / apollo-client

:rocket:  A fully-featured, production ready caching GraphQL client for every UI framework and GraphQL server.
https://apollographql.com/client
MIT License
19.38k stars 2.66k forks source link

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

Open kodai3 opened 10 months ago

kodai3 commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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 commented 9 months ago

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

Maxou44 commented 7 months ago

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

jerelmiller commented 7 months ago

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 https://github.com/graphql/graphql-spec/pull/1077 and https://github.com/graphql/graphql-spec/pull/1074). We'd like to avoid confusion/bundle size while we are still unsure what the final format will be.