Variable types are not validated

[BrynCooke]

Describe the bug
When passing in variables their types should be validated against the schema and the entire request rejected if they are incorrect.

Requires schema parsing to complete.

[cecton]

I analyzed a bit and I would need to make quite some abstraction to make it all work. I think it would be best to wait for the higher level API @lrlna will be making on apollo-parser.

@BrynCooke I was wondering if implementing the code to solve this issue is actually a good idea: this will slow down the router a little bit and since it's the variables it can't be entirely cached. The type validation itself is already done by the subgraphs. Why not just raise the errors and call it a day?

[cecton]

Oh I see. The errors will match the sub queries variables, not the original variables which might differ.

[BrynCooke]

If it's simple I would be tempted to implement this:

1. to get us towards where we need to be in terms of router functionality.
2. to enable us to feed requirements back to apollo-rs.

What do you think though? It's throw away code for sure.

@lrlna The timescales for the HIR will inform our decision on the above. Do you think it would be feasible to jump ahead and start contributing to an HIR in apollo-rs relatively soon? Otherwise there is probably still benefit from a stop-gap solution.

[lrlna]

@BrynCooke here is the current plan for semantic analysis that I think will be able to accommodate for other people to contribute to the work some time in the second part of January:

1. I have a pretty good idea of how I'd like to design the library, but I am very keen to do a spike first.
2. Once the spike is complete I will be in a position to thoroughly breakdown the work into smaller chunks that could be divided between myself and another implementor (or 2!). This is important as I like to make sure that the work we are doing is thought out, deliberate, and facilitates the needs of other tooling that will also be using this library. Timeline-wise, this will bring us close to holiday season.
3. If my current idea is proved to be reasonable during the spike, it will be easiest if I set up a barebones architecture first before other contributors come on board. Otherwise we are in a situation of too many cooks. This is likely to spill over to just after the holidays.
4. After this, I think you can start contributing with a lot more ease.

How does this sound to you?

[BrynCooke]

Thanks @lrlna, this sounds great.

Given this information I am +1 to a stopgap on the router side with the intention of replacing with the apollo-rs HIR when it makes sense to do so.

[cecton]

Closed by mistake