Variables and Context

[bruce]

Besides arguments, there are two additional sources of values for resolution: execution variables (which should relate to variables declared in the query document and probably provided by HTTP params, etc) and context (which are additional, system-provided values like the current user, etc). Notably, the difference here is that variables are should be of type %{binary => any}, where context can be %{any => any} (and, in practice, will probably be %{atom => any}).

This PR deconflates execution variables and context and adds testing, changes needed to ensure variables are being looked up correctly.

[benwilson512]

Question: How are the variables passed along with a request? Are they additional http parameters or something? Is there a special section of the graphql doc for them?

[bruce]

Example:

Yes; it's really up to how you feed the values into ExGraphQL.run, but the expected usage would be:

POST /api/linen?thingId=12
Content-Type: application/graphql

query GimmeThingByVariable($thingId: Int!) {
  thing(id: $thingId) {
    name
  }
}

[bruce]

And that's the "client provides the document" approach. Later, if we stored the docs server-side, it could be something like:

POST /api/linen?doc=nameOfDocumentWithManyOperations&operation=GimmeThingByVariable&thingId=12
Content-Type: application/graphql

Where doc would pull in the appropriate query document from storage, and operation would select the operation to execute (since you can actually have multiple operations declared in a document; you just have to select a single one to execute)

[bruce]

Oh, boy did this turn out to be more complex than I thought. Pretty good result, though -- support for error reporting on missing values (but still executing the document), support for defaults, etc. I'm going to merge this down and make a PR to support these changes in our project.