c2f0dd2aec
* 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
|
||
|---|---|---|
| .github/ISSUE_TEMPLATE | ||
| _build | ||
| assets/logo | ||
| benches | ||
| docs/book | ||
| examples/warp_async | ||
| integration_tests | ||
| juniper | ||
| juniper_benchmarks | ||
| juniper_codegen | ||
| juniper_hyper | ||
| juniper_iron | ||
| juniper_rocket | ||
| juniper_rocket_async | ||
| juniper_warp | ||
| .gitignore | ||
| .travis.yml | ||
| azure-pipelines.yml | ||
| Cargo.toml | ||
| CONTRIBUTING.md | ||
| LICENSE | ||
| Makefile.toml | ||
| README.md | ||
| RELEASING.md | ||
| rustfmt.toml | ||
GraphQL server library for Rust
GraphQL is a data query language developed by Facebook intended to serve mobile and web application frontends.
Juniper makes it possible to write GraphQL servers in Rust that are type-safe and blazingly fast. We also try to make declaring and resolving GraphQL schemas as convenient as possible as Rust will allow.
Juniper does not include a web server - instead it provides building blocks to make integration with existing servers straightforward. It optionally provides a pre-built integration for the Hyper, Iron, Rocket, and Warp frameworks, including embedded Graphiql and GraphQL Playground for easy debugging.
- Cargo crate
- API Reference
- Book: Guides and Examples (current | master)
The book is also available for the master branch and older versions published after 0.11.1. See the book index.
Getting Started
The best place to get started is the Juniper Book, which contains guides with plenty of examples, covering all features of Juniper. (very much WIP)
To get started quickly and get a feel for Juniper, check out the Quickstart section.
For specific information about macros, types and the Juniper api, the API Reference is the best place to look.
You can also check out src/tests/schema.rs to see a complex schema including polymorphism with traits and interfaces. For an example of web framework integration, see the hyper, rocket, iron, and warp examples folders.
Features
Juniper supports the full GraphQL query language according to the specification, including interfaces, unions, schema introspection, and validations. It does not, however, support the schema language. Consider using juniper-from-schema for generating code from a schema file.
As an exception to other GraphQL libraries for other languages, Juniper builds
non-null types by default. A field of type Vec<Episode> will be converted into
[Episode!]!. The corresponding Rust type for e.g. [Episode] would be
Option<Vec<Option<Episode>>>.
Integrations
Data types
Juniper has automatic integration with some very common Rust crates to make building schemas a breeze. The types from these crates will be usable in your Schemas automatically.
Web Frameworks
Guides & Examples
API Stability
Juniper has not reached 1.0 yet, thus some API instability should be expected.