fe86dbb782
* Mark `Arc` with `IsInputType` & `IsOutputType`. We've just updated a service we work with to the latest release of juniper (it's been on a fairly old master commit for some time). In this service we have some fields that are contained within `Arc`s, which I added support for in #479. Since then it seems the new marker traits of `IsInputType` & `IsOutputType` have been added, but they do not support `Arc`, leading to: ``` error[E0277]: the trait bound `Arc<menu::Menu>: IsOutputType<__S>` is not satisfied --> src/graphql.rs:36:1 | 36 | #[juniper::graphql_object(Context=Context)] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `IsOutputType<__S>` is not implemented for `Arc<menu::Menu>` | = note: required by `juniper::marker::IsOutputType::mark` = note: this error originates in an attribute macro (in Nightly builds, run with -Z macro-backtrace for more info) ``` This commit adds support for those, mirroring the support for `Box`. I'm not sure if there's a good place to add a test for this functionality so that regressions can be avoided in the future? * Add Arc tests & FromInputValue for Arc<T> |
||
|---|---|---|
| .github | ||
| _build | ||
| assets/logo | ||
| docs/book | ||
| examples | ||
| integration_tests | ||
| juniper | ||
| juniper_actix | ||
| juniper_benchmarks | ||
| juniper_codegen | ||
| juniper_graphql_ws | ||
| juniper_hyper | ||
| juniper_iron | ||
| juniper_rocket | ||
| juniper_rocket_async | ||
| juniper_subscriptions | ||
| juniper_warp | ||
| .gitignore | ||
| 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 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 Actix, 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 the Star Wars schema to see a complex example including polymorphism with traits and interfaces. For an example of web framework integration, see the actix, 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 can also output the schema in the GraphQL Schema Language.
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>>>.
Juniper follows a code-first approach to defining GraphQL schemas. If you would like to use a schema-first approach instead, consider juniper-from-schema for generating code from a schema file.
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.