* Validate variables of the executed operation only
* Use `unreachable!` in `validate_var_defs`.
Use `unreachable!` instead of `panic!` on invalid variable types,
since thay have already been checked during document validation.
* Fix formatting in `validation/input_value.rs`
The `uuid` maintainers have started releasing in the `0.8` version train. I've relaxed the version requirements on `juniper`'s dependencies to allow juniper users to specify a different version in their `Cargo.toml` and still have the integration work.
* Implement GraphQLTypeAsync for Arc
I'm building a GraphQL API using Juniper that proxies another GraphQL
API. It does a large fetch upfront from the underlying GraphQL API,
transforms it into a different format and then implements some
resolvers that do some further filtering.
One of these resolvers ends up looking like:
```
async fn items(&self, ...) -> Vec<Item> {
self.items.iter().filter(...).collect()
}
```
This causes us problems as we're returning owned Item's and Item is a
large nested structure that would be expensive to clone.
Our current work around was to put Item into an Arc, as Arc is
comparatively cheap to clone. So our method becomes:
```
async fn items(&self, ...) -> Vec<Arc<Item>> {
self.items.iter().filter(...).map(Arc::clone).collect()
}
```
However to support this we needed Arc to implement GraphQLTypeAsync.
This commit adds that support to juniper, by forwarding to the
GraphQLTypeAsync implementation for the contained type.
It's possible that we could have acheived something similar by adding
some lifetimes to our resolver and returning a reference, but using an
Arc was easier for us in this case. I'm not sure if there's any reason
why this would be a bad addition to Juniper overall?
* Move GraphQLTypeAsync for Arc<T> into pointers.rs
* Validate variables of the executed operation only
* Use `unreachable!` in `validate_var_defs`.
Use `unreachable!` instead of `panic!` on invalid variable types,
since thay have already been checked during document validation.
* Fix formatting in `validation/input_value.rs`
The `uuid` maintainers have started releasing in the `0.8` version train. I've relaxed the version requirements on `juniper`'s dependencies to allow juniper users to specify a different version in their `Cargo.toml` and still have the integration work.
