Iron-Ham
commented
1 year ago I spoke with @calvincestari around getting @defer support in apollo-ios.
There's an ongoing stream of work related to supporting multipart/mixed HTTP requests. To support any kind of incremental transport over HTTP[^1], this work must be completed first.
Once this work has merged, supporting @defer can come in a variety of flavors. I expect that @defer will have the following impacts:
-
Impact on code generation. Code generation must be impacted when a selection set is deferred. There are questions about how best to do that. The simplest is perhaps to wrap the selection set in an additional layer of
Optional, although I fear that this may not convey what's happening to the end user. For example, if I have linked a Twitter account to my GitHub profile, and I@deferretrieval of that information, the generated property would read something likevar twitterProfileUrl: String?? { ... }. That's a bit funky, and perhaps doesn't convey that this field will arrive as aString?based on whether the user does or does not have a Twitter profile linked to their GitHub account. Instead, I propose that we explore the possibility of something like this:enum ApolloDeferredResponse<T> { case loading case result(Result<T, Error>) }Such that this selection set is now wrapped within this property. I think this may well have some effects down the chain (e.g., is
SomeFragment?comparable toApolloDeferredResponse<SomeFragment>?), but it's certainly an idea worth exploring. I'd say that it's certainly a nice to have that could follow an initial proof of concept implementation with optionals. -
Impact on inclusion directives: We should certainly think about and test the ergonomics of using the generated code if it's been generated with
@skipand@includedirectives. -
Impact on watchers: My assumption for how defer would work is that the incremental responses would pull the record from the cache (in-memory, SQLite, what have you), update/append it with new data, and save it back to the cache. That will certainly trigger a watcher update. Additionally, for a first implementation, we should return incremental callbacks (including the full record as received from previous parts). For folks using the watcher, this will mean getting the data multiple times. This seems likely fine for a first pass at
@deferand can be improved upon in future iterations.
Once the support for multipart/mixed is in place, I'd be happy to begin exploring this in collaboration with y'all.
calvincestari
john-twigg-ck
epitaphmike
fabiengasser
loganblevins
One of the disadvantages of GraphQL’s request/response model is that the GraphQL response is not returned to clients until the entire request has finished processing. However, not all requested data may be of equal importance, and in some use cases it may be possible for applications to act on a subset of the requested data. An application can speed up its time-to-interactive if the GraphQL server can send the most important data as soon as it’s ready. The new
@deferand@streamdirectives allow GraphQL servers to do exactly that by returning multiple payloads from a single GraphQL response.Similar to
@streamthe@deferdirective also allows the client to receive data before the entire result is ready.@streamcan be used on list fields. Whereas@defercan be used on used on fragment spreads and inline fragments.References
https://graphql.org/blog/2020-12-08-improving-latency-with-defer-and-stream-directives/