The previous implementation used a futures_cpupool for executing
blocking juniper operations. This pool comes in addition to the
thread pool started by hyper through tokio for executing hyper's futures.
This patch uses tokio::blocking to perform the blocking juniper
operations while re-using the same thread pool as hyper, which
simplifies the API.
* Bump` juniper`, `juniper_codegen`, and `juniper_tests` versions.
* Bump integration crate requirements to include 0.10.0. `juniper_iron` gets a semver breaking version as it has a breaking change but `juniper_iron` does not.
* Move `juniper_rocket` changelog into one file. This aligns with `juniper_iron` and will be easier
to automate in the future.
* Let `juniper_warp` and `juniper_hyper` use `0.9.x` versions of Juniper. They don't rely on anything in 0.10.0 so don't require it.
Fields can now be skipped with the `#[graphql(skip)]` annotation. Note this
doesn't really make sense for GraphQLInputObjects so this isn't supported there.
Fixes https://github.com/graphql-rust/juniper/issues/220.
This enables Rust2018-style macro imports:
```rust
use juniper::graphql_object;
graphql_object!(User: () |&self| { ... });
```
In the future when dropping compatibility with pre-2018 compilers,
this can be replaced with the explicit `$crate` prefixes instead of
`local_inner_macros`.
In `macro_rules!` with the annotation `local_inner_macros`, all of macro calls
are transformed into `$crate::builtin!(...)` (See [1] for details).
Therefore, name resolutions of built-in macros are not perfomed correctly.
To avoid this, some helper macros are introduced to make built-in
macros be interpreted as crate-local macros.
[1]: https://github.com/rust-lang/rust/issues/53464#issuecomment-414049821
Performance improvements
* Replace the IndexMap in the serialized object with a plain
`Vec<(String, Value)>` because linear search is faster for few
elements
* Some general tweaks to skip some allocations
It appears with newer 0.10.x hyper it no longer takes "{" or "}" in the
query string unescaped.
When I tried to set `juniper_iron` to an older hyper it complained that it
couldn't resolve due to `juniper_rocket` needing a newer version.
This was the path of least resistance. Note that we are still testing the same
thing, this change is needed as a consequence of how `iron_test` creates mock
requests.
Fixes https://github.com/graphql-rust/juniper/issues/206
* Added trait to convert a custom error type into a FieldError
* Convert the error type of the gql fields if it implements IntoFieldError
* Added test case to check if custom error handling works
* Added to changelog
GraphQL spec requires every error contain `{"message": "field"}`. Every
error in juniper except ones fixed here are reported consistently with
this style. This commit fixes ones left.
If a field has a description, we properly generate a meta field definition like:
```rust
{
let field = registry.field::<String>("id", &());
let field = field.description("Whatever");
field
}
```
If a field does not have a description, we were generating something like:
```rust
{
let field = registry.field::<String>("id", &());
let field = field; // <--- Note not needed
field
}
```
This of course works (and was likely optimized out by the compiler), but bloats
generated code for no benefit.
This change merely makes the second case generate:
```rust
{
let field = registry.field::<String>("id", &());
field
}
```
Fixes https://github.com/graphql-rust/juniper/issues/185.
* use prebuilt cargo-make for travis build
* use prebuilt cargo-make for travis build
* use prebuilt cargo-make for travis build
* use prebuilt cargo-make for travis build
* use prebuilt cargo-make for travis build
