Add option to pass schema as string, fixes #59

[christophercliff]

Attempted fix for #59. Could you please let me know if this is looks appropriate and what's expected in terms of test?

TODO:

• Make sure all of the significant new logic is covered by tests
• Rebase your changes on master so that they can be merged easily
• Make sure all tests pass
• Update CHANGELOG.md with your change
• If this was a change that affects the external API, update the README

[apollo-cla]

@christophercliff: Thank you for submitting a pull request! Before we can merge it, you'll need to sign the Meteor Contributor Agreement here: https://contribute.meteor.com/

[jnwng]

@christophercliff beautiful, i was just working on this too! glad you got it all working. left a couple of comments, and do you mind filling out the Meteor CLA?

[jnwng]

i dont think you want to replace this — you should add a separate block of tests for this

[jnwng]

what do you think about using typeDefs instead? its a term i saw a lot in graphql-tools when referring to the schema when defined via the IDL

[christophercliff]

makeExecutableSchema() defines typeDefs:

typeDefs is a required argument and should be an array of GraphQL schema language strings or a function that takes no arguments and returns an array of GraphQL schema language strings. The order of the strings in the array is not important, but it must include a schema definition.

That's not exactly what's used here. Alternatively, buildSchema() just refers to it as source. printSchema() refers to it as "schema in the Schema Language format".

I think schemaString is a decent compromise given the ambiguity and that the API is already using schemaJson.

[jnwng]

also, do you mind updated the README accordingly?

[christophercliff]

@jnwng Please see updates. Could you give me an idea when this might be published?

[jnwng]

thank you @christophercliff! this should be available in [email protected] (which is live)