Add support for defer and stream directives (feedback is welcome)

[robrichard]

This branch is being published to npm as express-graphql@experimental-stream-defer

Continued from #583

References:

• Issue for feedback
• Demo repo
• defer/stream RFC
• Spec edits
• graphql-js PR
• graphql-over-http RFC

[acao]

This PR is looking fantastic! locally with a simple express server its working great. with the demo schema resolvers I made, and a query such as the one below, I can mimic mixed rapid or high latency streams by setting a delay argument

we have a PR that implements this branch in graphiql:
graphql/graphiql#1770

I figured out a way to make it actually update state with every multipart increment. in 2.0 this will be handled with a much more performant state management strategy, but for now it seems fine.

we now have a (mostly) working netlify deploy preview, using a query like this:

{
  isTest
  stream: streamable(delay: 500) @stream(initialCount: 2) {
    text
  }
  anotherStream: streamable(delay: 200) @stream(initialCount: 0) {
    text
  }
}

notice how it waits and then batches all the increments at the end so it looks like a normal, very delayed request? and if you increase the delay, the more it delays the whole request.

what I'm guessing is that netlify's CDN is batching the multipart requests somehow? i can't seem to increase the delay to a point that changes this, so I wonder what else I'm missing.

I used aws-serverless-express which is deprecated, but seems to work fine for normal POST and GET requests? we use it for swapi-graphql. maybe will try out serverless-http instead.

We added multipart/mixed to the list of known mime types as well

I apologize if this question is not relevant to the PR discussion, and if so can move this comment over to our PR!

[maraisr]

Hi @IvanGoncharov im working with @acao around getting defer/stream into GraphiQL and was wondering if you could do us a solid and cut a release under the current experimental tag (or whatever you feel) that includes 633ca8b.

meros (used by graphiql now) depends on this behavior being present, as the timing of flushing chunks with boundaries is critical, largely based on latest "spec proposal" updates.