Make the executor and validation APIs public to enable split parsing and execution

[jerel]

Making these APIs public is based on my understanding of #773 (comment) and #773 (comment)

This PR is related to #776, #726, and enables features similar to #843 to be implemented in user land code. In my project I'm currently doing this (pseudo code) in the first step:

fn compile() {
  let document = parse_document_source(document_source, &root_node.schema)?;
  visit_all_rules(&mut ctx, &document);
  let operation = get_operation(&document, operation_name)?;
  Ok((document.clone(), operation.clone()))
}

so I can make use of the operation and document and then in the second step I'm using the [now public] validation::validate_input_values and executor::execute_validated_query_async or resolve_validated_subscription as needed.

Thoughts on these changes?

[jerel]

@LegNeato @ccbrown what are your thoughts on this proposed change?

Being able to precompile queries while checking them against the schema is a big requirement of a project I'm working on and ideally we could implement it in a way that stays aligned with this project.

[ccbrown]

To sum up my thoughts from the linked issues:

• This is really valuable functionality that we should have in some form.
• Ideally parsing wouldn't require knowledge of the schema. Unfortunately eliminating the parser's dependency on the schema isn't trivial. @mirosval made a valiant effort in refactor: remove ScalarValue type parameter #782, but it fell through. Given the value of this functionality and the lack of a clear path towards eliminating the parser's schema dependency, I'm okay moving forward with exposing whatever's necessary for this functionality anyway.
• I have a preference for exposing this functionality in the inner crates (juniper::parser, juniper::validation, etc.) rather than the top level juniper crate, just for the sake of keeping the top level API narrow.

[LegNeato]

Sorry this took so long. Can you add an integration test that uses the API so we can be sure to not regress?

[LegNeato]

Thank you! 🍻

[LegNeato]

This is now on crates.io. Thank you again!

[mrtnzlml]

Hey @jerel! 👋 I have a question regarding this PR. Say you want to implement persistent queries, so in the first step, you parse and validate the query and save it to DB (so it can be accessed later while skipping validations). My question is: how should the validated query be stored in DB? Do you store it as a string (meaning that you must call parse_document_source later again)? Or is there a better way to skip the parsing on future requests? Thanks! :)

[jerel]

@mrtnzlml good question... I think I would experiment with storing the string versus a lightweight binary approach like bincode. I forget the nuances of this query API but it's possible that something like this would work and would save the effort of parsing the string tokens a second time. Example (untested):

// store
let document = parse_document_source(document_source, &root_node.schema)?;
visit_all_rules(&mut ctx, &document);
let operation = get_operation(&document, operation_name)?;
let store_me = bincode::serialize(&(document, operation)).unwrap();

// later
let (document, operation): (Document, Operation) = bincode::deserialize(&store_me).unwrap();
validate_input_values();
execute_validated_query_async();