Implement ＠defer "June 2023" response format #6331
Conversation
✅ Docs Preview ReadyConfiguration{
"repoOverrides": {
"apollographql/apollo-kotlin@main": {
"remote": {
"owner": "apollographql",
"repo": "apollo-kotlin",
"branch": "defer-incremental-response-format-june-2023"
}
}
}
}
1 pages published. Build will be available for 30 days. |
BoD
force-pushed
the
defer-incremental-response-format-june-2023
branch
from
e2da859 to
bb504f6
Compare
✅ Docs preview has no changesThe preview was not built because there were no changes. Build ID: c8d256329554a5b39384233f |
BoD
force-pushed
the
defer-incremental-response-format-june-2023
branch
2 times, most recently
from
e1ee642 to
4fa99ad
Compare
|
Apollo Client 4 introduces different handlers for different incremental formats. We could do the same while the format iterates. |
BoD
force-pushed
the
defer-incremental-response-format-june-2023
branch
3 times, most recently
from
fc4f174 to
8dfc4b3
Compare
...lo-api/src/commonMain/kotlin/com/apollographql/apollo/api/http/DefaultHttpRequestComposer.kt
Outdated
Show resolved
Hide resolved
...lo-api/src/commonMain/kotlin/com/apollographql/apollo/api/http/DefaultHttpRequestComposer.kt
Outdated
Show resolved
Hide resolved
...otlin/com/apollographql/apollo/internal/incremental/Defer20220824IncrementalResultsMerger.kt
Outdated
Show resolved
Hide resolved
.../commonMain/kotlin/com/apollographql/apollo/internal/incremental/IncrementalResultsMerger.kt
Outdated
Show resolved
Hide resolved
| this.engine = httpEngine | ||
| } | ||
|
|
||
| fun incrementalDeliveryProtocol(incrementalDeliveryProtocol: IncrementalDeliveryProtocol) = apply { |
There was a problem hiding this comment.
Missing KDoc here
Also, looks like apollo-client went with incrementalHandler. Might be worth reusing some of the terminology? But we also have "protocol" for other things like WebSockets so my logaf is low.
| public final class com/apollographql/apollo/internal/incremental/Defer20220824IncrementalResultsMerger : com/apollographql/apollo/internal/incremental/IncrementalResultsMerger { | ||
| public fun <init> ()V | ||
| public fun getHasNext ()Z | ||
| public fun getIncrementalResultIdentifiers ()Ljava/util/Set; | ||
| public fun getMerged ()Ljava/util/Map; | ||
| public fun isEmptyResponse ()Z | ||
| public fun merge (Ljava/util/Map;)Ljava/util/Map; | ||
| public fun merge (Lokio/BufferedSource;)Ljava/util/Map; | ||
| public fun reset ()V | ||
| } | ||
|
|
||
| public final class com/apollographql/apollo/internal/incremental/GraphQL17Alpha9IncrementalResultsMerger : com/apollographql/apollo/internal/incremental/IncrementalResultsMerger { |
There was a problem hiding this comment.
It's a bit weird that one is Defer20220824 and the other GraphQL17Alpha9. I haven't followed all the latest discussions lately but could we somwhat uniformized that? Are there specs versions (or tags) somewhere that describe what each one is doing?
There was a problem hiding this comment.
It doesn’t look like there are any tags on the spec itself, so using graphql-js versions is cool. So maybe we should rename Defer20220824 to whatever version of graphql-js it corresponds to, for consistency. For now I kept the same naming as Apollo Client, but maybe it’s not too late to change the name there too.
There was a problem hiding this comment.
Sounds good. Let's keep a practical approach here and do whatever is easiest. This is all experimental so the whole point is to move fast and iterate 👍
There was a problem hiding this comment.
In the end, I opted for this naming in the API:
DraftInitial: our initial implem, still the defaultDraft0_1: what will be on https://specs.apollo.dev/incremental/v0.1/ very soon
There was a problem hiding this comment.
Actually, what about:
Incremental0_0Incremental0_1
?
There was a problem hiding this comment.
Yes I like it! But then it would make sense to have specs.apollo.dev/incremental/v0.0 to match it.
There was a problem hiding this comment.
it would make sense to have specs.apollo.dev/incremental/v0.0 to match it.
Yea, would be nice of course but if we don't have time for this, I think it's still fine. Besides me, everyone finds 0.0 to be a weird version name. So I think most people would understand if 0.0 is "unreleased initial version"
There was a problem hiding this comment.
If we don't have it, add a KDoc comment: "0.0 is the @defer protocol used as of 20220824. It has not been specified and is kept for backward compatibility reasons", something like this.
...-runtime/src/commonMain/kotlin/com/apollographql/apollo/network/http/HttpNetworkTransport.kt
Outdated
Show resolved
Hide resolved
...Main/kotlin/com/apollographql/apollo/internal/incremental/IncrementalDeliveryProtocolImpl.kt
Outdated
Show resolved
Hide resolved
...-runtime/src/commonMain/kotlin/com/apollographql/apollo/network/http/HttpNetworkTransport.kt
Outdated
Show resolved
Hide resolved
...lo-api/src/commonMain/kotlin/com/apollographql/apollo/api/http/DefaultHttpRequestComposer.kt
Outdated
Show resolved
Hide resolved
...Main/kotlin/com/apollographql/apollo/internal/incremental/IncrementalDeliveryProtocolImpl.kt
Outdated
Show resolved
Hide resolved
libraries/apollo-api/src/commonMain/kotlin/com/apollographql/apollo/api/Executables.kt
Outdated
Show resolved
Hide resolved
| payloadResponse != null -> payloadResponse | ||
| else -> null | ||
| } | ||
| } else { |
There was a problem hiding this comment.
Is there a way to test from the response whether it supports the incremental delivey protocol? Is there something in response.headers["content-type"] that signals what protocol was used by the server?
…gmentIdentifier -> IncrementalResultIdentifier
… configuration. Defaults to the legacy one.
…efaultHttpRequestComposer
BoD
force-pushed
the
defer-incremental-response-format-june-2023
branch
from
76ff55c to
97177bd
Compare
3 participants
Implements the latest (as of 2025-09-24) ＠defer incremental response format as seen in examples and spec edits.
A protocol can now be passed to the
HttpNetworkTransportto choose which to use (legacy20220824is still the default).