defer stream support within stitching

[yaacovCR]

A work in progress...

Help wanted...

• test single proxied deferred patch.
• test merging deferred patches from multiple subschemas
• handle stream

In terms of mechanism, have settled on external values that are from asyncIterables being converted to an initial result with an associated Receiver object, which is passed down the execution tree. If a field is not present on the result, and a Receiver can be found, the default merging resolver will request to be notified when the field is available.

• think more broadly about how to implement the Receiver, maybe we should use Repeaters rather than raw async iterables, and what the best pattern is for consuming async iterables.... see Not that great for implementing transducers? repeaterjs/repeater#48 (comment)

• update all transforms that touch results - some result transformers parse the request and transform the response based on saved state -- these transformers may require rewriting patch labels so that state does not overlap between different fragments...

  • CheckResultAndHandleErrors (merging errors into results) - replaced by externalValueFromResult and externalValueFromPatchResult functions
  • TransformQuery
  • MapLeafValues
  • RenameRootTypes
  • RenameTypes
  • TransformCompositeFields
  • WrapFields
  • HoistFields

• update batch-execute

• update batch-delegate

• test errors

• test timeouts

graphql/graphql-js#2319
graphql/graphql-spec#742

[sshevlyagin]

So... is this done? #4796 :D

[yaacovCR]

Not yet :( still can't stitch

[maxbol]

Hi @yaacovCR ! Do you know if this will solve other async/persistent connections, like @n1ru4l 's live query pattern, in stitched schemas?

I would love to assist with this goal in any way possible!