refactor(graphql): extract graphql() logic into graphql$UCCF to suppo…

[xareelee]

This PR is for discussion only, not for real merge.

This PR demonstrates how to convert a Promise-based function to a reactive-callback-based function to support all kinds of async handling system without any new dependency.

We use promisify() to turn it back to a Promise-based function for the default flavor.

It currently is not reactive yet due to the upstream functions are not reactive (as Promise). We need to refactor all upstream functions to be reactive-callback-based.

More discussions on #647.

TODO

• make first refactor demo and pass the tests and lint.
• add strict Flow type and pass the type check.
• refactor the upstream functions of graphql to be reactive-callback-based (UCC functions) until it fully supports reactive programming.

For more info on UCC functions, please refer to this article.

[facebook-github-bot]

Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. In order for us to review and merge your code, please sign up at https://code.facebook.com/cla - and if you have received this in error or have any questions, please drop us a line at cla@fb.com. Thanks!

If you are contributing on behalf of someone else (eg your employer): the individual CLA is not sufficient - use https://developers.facebook.com/opensource/cla?type=company instead. Contact cla@fb.com if you have any questions.

[leebyron]

Can you clarify the purpose of this PR? If you would like to use a callback interface with GraphQL, you can wrap the existing function that returns a Promise by proving your callback function to the "then" method.

I see that this adds complexity, but I don't see the value

[xareelee]

Hi @leebyron,

This is unfinished PR. Currently I just publish this PR for discussion.

Using callback-based functions to support reactive events without any 3rd-party dependency (e.g. Rx) is the value.

Promise-based functions can not be reactive due to they only can send one value for their lifetime. We can not use Promises as the reactive event sources to send values continuously.

Converting the event handling of this library from Promise to reactive-callback system would be friendly to the FRP world. Users could then choose how to use this library — Promise-based or FRP-based (any flavor).

My goal is to make this library be reactive without any 3rd-party dependency, so we can send reactive events to resolvers and make graphql-js subscribable to receive data changes.

If adopting the reactive-callback design, we don't need to maintain another reactive version of graphql-js. When finishing this branch, we can make graphql-js return an Rx.Observable (or using any other FRP library):

// Promise flavor
const graphqlPromise = promisify(graphql$UCCF);
graphqlPromise(schema, query).then(...);

// Rx flavor
const graphqlRx = rxify(graphql$UCCF);
grapqlRx(schema, query).subscribe(...);

I'm building a front-end data flow framework based on graphql-js. I need it to be reactive.

[leebyron]

Thanks that helps me understand.

Please refer to #502 where this was discussed at greater length. The goal of graphql-js is to be a production grade spec compliant reference implementation with readable and reusable source. As I mentioned in that issue, I'm very excited about the explorations in different ways to implement live systems in GraphQL, however I do not think it's appropriate to do that at the expense of making this particular library worse at its intended goals. I would encourage you to explore this kind of experimental off-spec behavior in a fork or additional library so that it can be fully explored without impact on this reference implementation