Add support for customParseFn option

[williambailey]

Attempt to address #483.

The current implementation in this PR provides support for synchronous customParseFn functions.

Eventually I think that it would be worthwhile also supporting asynchronous functions. i.e. have the customParseFn return type be a (let's see if i get the Flow type correct) ?Promise<DocumentNode>. Unfortunitely I couldn't quite get the promise handling .then().catch() logic right at this point in time... even when requiring the customParseFn be async (vs. maybe async).

[IvanGoncharov]

@williambailey Thanks for PR 👍

Eventually I think that it would be worthwhile also supporting asynchronous functions. i.e. have the customParseFn return type be a (let's see if i get the Flow type correct) ?Promise. Unfortunitely I couldn't quite get the promise handling .then().catch() logic right at this point in time... even when requiring the customParseFn be async (vs. maybe async).

You don't need async since options callback can return promise of options:

graphqlHTTP(graphqlHTTPOptions); function graphqlHTTPOptions(request, response, params) { return getASTFromCache(params.query).then(ast => { schema, customParseFn() { return ast; } }) }

Every time you add .then it forces the node to switch to the next task in even loop and this adds performance penalty so it makes sense to batch all async jobs in options callback.
Also, it makes source code easier to read and reason about.

Note: you also get params inside options callback so it doesn't make sense to change the signature of parse from graphql-js. So can you please change customParseFn to:

customParseFn?: ?(source: Source) => DocumentNode, 

[williambailey]

Completely forgot that you could return a promise of options. PR updated.

[IvanGoncharov]

@williambailey Can you please revert this line?

[IvanGoncharov]

@williambailey Thanks 👍
Merged 🎉
I will try to release NPM 📦 next week.

[IvanGoncharov]

@williambailey Sorry for delay. I just published 0.9.0 📦