[0.15.10] 2022-07-28
- Fix CVE-2022-31173.
- Fix incorrect error when explicit
nullprovided fornullable list input parameter. (#1086)
[0.15.9] 2022-02-02
- Fix infinite recursion on malformed queries with nested recursive fragments. This is a potential denial-of-service attack vector. Thanks to @quapka for the detailed vulnerability report and reproduction steps.
[0.15.8] 2022-01-26
- Fix panic on malformed queries with recursive fragments. This is a potential denial-of-service attack vector. Thanks to @quapka for the detailed vulnerability report and reproduction steps.
[0.15.7] 2021-07-08
- Fix panic on spreading untyped union fragments (#945)
[0.15.6] 2021-06-07
- Allow
RootNode::as_schema_languageandRootNode::as_parser_documentfor arbitrary type info (#935)
[0.15.5] 2021-05-11
- Fix multiple fragments on sub types overriding each other (#927)
- Fix error extensions in subscriptions (#927)
- Fix fields on interfaces not being resolved when used with fragments (#923)
[0.15.4] 2021-04-03
- Un-deprecate select_child, has_child, and child_names methods (#900)
[0.15.3] 2021-01-27
[0.15.2] 2021-01-15
- Update GraphQL Playground to v1.7.27.
- Add marker GraphQL trait implementations for Rust container types like
Box(#847)
[0.15.1] 2020-12-12
- Support
Arcin input and output objects. (#822)
[0.15.0] 2020-12-09
Features
-
Added async support. (#2)
execute()is now async. Synchronous execution can still be used viaexecute_sync().- Field resolvers may optionally be declared as
asyncand return a future.
-
Added experimental support for GraphQL subscriptions. (#433)
-
Added support for generating the GraphQL Schema Language representation of a schema using
RootNode::as_schema_language(). (#676)- This is controlled by the
schema-languagefeature and is on by default. It may be turned off if you do not need this functionality to reduce dependencies and speed up compile times. - Note that this is for generating the GraphQL Schema Language representation from the Rust schema. For the opposite--generating a Rust schema from a GraphQL Schema Language file--see the
juniper_from_schemaproject.
- This is controlled by the
-
Most GraphQL spec violations are now caught at compile-time. (#631)
- The enhanced error messages now include the reason and a link to the spec.
For example, if you try to declare a GraphQL object with no fields:
error: GraphQL object expects at least one field --> $DIR/impl_no_fields.rs:4:1 | 4 | impl Object {} | ^^^^^^^^^^^^^^ | = note: https://spec.graphql.org/June2018/#sec-Objects
- The enhanced error messages now include the reason and a link to the spec.
For example, if you try to declare a GraphQL object with no fields:
-
Raw identifiers are now supported in field and argument names.
-
Most error types now implement
std::error::Error. (#419)GraphQLErrorLexerErrorParseErrorRuleError
-
Support
chrono-tz::Tzscalar behind achrono-tzfeature flag. (#519) -
Added support for distinguishing between between implicit and explicit null. (#795)
-
Implement
IntoFieldErrorforstd::convert::Infallible. (#796) -
Allow using
#[graphql(Scalar = DefaultScalarValue)]for derive macroGraphQLScalarValue(#807)
Fixes
-
Massively improved the
#[graphql_union]proc macro. (#666):- Applicable to traits.
- Supports custom resolvers.
- Supports generics.
- Supports multiple
#[graphql_union]attributes.
-
Massively improved the
#[derive(GraphQLUnion)]macro. (#666):- Applicable to enums and structs.
- Supports custom resolvers.
- Supports generics.
- Supports multiple
#[graphql]attributes.
-
Massively improved the
#[graphql_interface]macro. (#682):- Applicable to traits and generates enum or trait object to represent a GraphQL interface (see the example of migration from
graphql_interface!macro). - Supports passing context and executor to a field resolver.
- Supports custom downcast functions and methods.
- Supports generics.
- Supports multiple
#[graphql_interface]attributes.
- Applicable to traits and generates enum or trait object to represent a GraphQL interface (see the example of migration from
-
The
GraphQLEnumderive now supports specifying a custom context. (#621)- Example:
#[derive(juniper::GraphQLEnum)] #[graphql(context = CustomContext)] enum TestEnum { A, }
-
Added support for renaming arguments within a GraphQL object. (#631)
- Example:
#[graphql(arguments(argA(name = "test")))] -
SchemaTypeis now public.- This is helpful when using
context.getSchema()inside of your field resolvers.
- This is helpful when using
-
Improved lookahead visibility for aliased fields. (#662)
-
When enabled, the optional
bsonintegration now requiresbson-1.0.0. (#678) -
Fixed panic on
executor.look_ahead()for nested fragments (#500)
Breaking Changes
-
GraphQLTypetrait was split into 2 traits: (#685)- An object-safe
GraphQLValuetrait containing resolving logic. - A static
GraphQLTypetrait containing GraphQL type information.
- An object-safe
-
juniper::graphiqlhas moved tojuniper::http::graphiql.juniper::http::graphiql::graphiql_source()now requires a second parameter for subscriptions.
-
Renamed the
objectproc macro tographql_object. -
Removed the
graphql_object!macro. Use the#[graphql_object]proc macro instead. -
Made
#[graphql_object]macro to generate code generic overScalarValueby default. (#779) -
Renamed the
scalarproc macro tographql_scalar. -
Removed the
graphql_scalar!macro. Use the#[graphql_scalar]proc macro instead. -
Removed the deprecated
ScalarValuecustom derive. UseGraphQLScalarValueinstead. -
Removed the
graphql_interface!macro. Use the#[graphql_interface]proc macro instead. -
Removed the
graphql_union!macro. Use the#[graphql_union]proc macro or custom resolvers for the#[derive(GraphQLUnion)]instead. -
The
#[derive(GraphQLUnion)]macro no longer generatesFromimpls for enum variants. (#666)- Consider using the
derive_morecrate directly.
- Consider using the
-
The
ScalarRefValuetrait has been removed as it was not required. -
Prefixing variables or fields with an underscore now matches Rust's behavior. (#684)
-
The return type of
GraphQLType::resolve()has been changed toExecutionResult.- This was done to unify the return type of all resolver methods. The previous
Valuereturn type was just an internal artifact of error handling.
- This was done to unify the return type of all resolver methods. The previous
-
Subscription-related:
- Add subscription type to
RootNode. - Add subscription endpoint to
playground_source(). - Add subscription endpoint to
graphiql_source().
- Add subscription type to
-
Specifying a scalar type via a string is no longer supported. (#631)
- For example, instead of
#[graphql(scalar = "DefaultScalarValue")]use#[graphql(scalar = DefaultScalarValue)]. Note the lack of quotes.
- For example, instead of
-
Integration tests:
- Renamed
http::tests::HTTPIntegrationashttp::tests::HttpIntegration. - Added support for
application/graphqlPOST request.
- Renamed
-
RootNode::new()now returnsRootNodeparametrized withDefaultScalarValue. For customScalarValueuseRootNode::new_with_scalar_value()instead. (#779) -
When using
LookAheadMethodsto access child selections, children are always found using their alias if it exists rather than their name. (#662)- These methods are also deprecated in favor of the new
LookAheadMethods::children()method.
- These methods are also deprecated in favor of the new
[0.14.2] 2019-12-16
- Fix incorrect validation with non-executed operations #455
- Correctly handle raw identifiers in field and argument names.
[0.14.1] 2019-10-24
[0.14.0] 2019-09-29
- Require
url2.x ifurlfeature is enabled. - Improve lookahead visitability.
- Add ability to parse 'subscription'.
[0.13.1] 2019-07-29
-
Fix a regression when using lookaheads with fragments containing nested types #404
-
Allow
mutarguments for resolver functions in#[object]macros #402
[0.13.0] 2019-07-19
newtype ScalarValue derive
See #345.
The newtype pattern can now be used with the GraphQLScalarValue custom derive
to easily implement custom scalar values that just wrap another scalar,
similar to serdes #[serde(transparent)] functionality.
Example:
#[derive(juniper::GraphQLScalarValue)]
struct UserId(i32);Other Changes
- The
IDscalar now implements Serde'sSerializeandDeserialize - Add support for
dyntrait object syntax to procedural macros
[0.12.0] 2019-05-16
object macro
The graphql_object! macro is deprecated and will be removed in the future.
It is replaced by the new object procedural macro.
2018 Edition
All crates were refactored to the Rust 2018 edition.
This should not have any impact on your code, since juniper already was 2018 compatible.
Other changes
- The minimum required Rust version is now
1.34.0. - The
GraphQLTypeimpl for () was removed to improve compile time safefty. #355 - The
ScalarValuecustom derive has been renamed toGraphQLScalarValue. - Added built-in support for the canonical schema introspection query via
juniper::introspect(). #307 - Fix introspection query validity The DirectiveLocation::InlineFragment had an invalid literal value, which broke third party tools like apollo cli.
- Added GraphQL Playground integration.
The
DirectiveLocation::InlineFragmenthad an invalid literal value, which broke third party tools like apollo cli. - The return type of
value::object::Object::iter/iter_muthas changed toimpl Iter. #312 - Add
GraphQLRequest::operation_name#353
[0.11.1] 2018-12-19
Changes
-
The minimum required Rust version is now
1.30. -
All macros and the custom derives now support the macro system changes properly and also support Rust 2018 edition crates.
[0.11.0] 2018-12-17
Changes
-
The minimum required Rust version is now
1.30.0. -
Juniper is now generic about the exact representation of scalar values. This allows downstream crates to add support for own scalar value representations.
There are two use cases for this feature:
- You want to support new scalar types not representable by the provided default
scalar value representation like for example
i64 - You want to support a type from a third party crate that is not supported by juniper
Note: This may need some changes in down stream code, especially if working with generic code. To retain the current behaviour use
DefaultScalarValueas scalar value type - You want to support new scalar types not representable by the provided default
scalar value representation like for example
-
The
GraphQLObjectandGraphQLEnumderives will mark graphql fields as@deprecatedwhen struct fields or enum variants are marked with the builtin#[deprecated]attribute.The deprecation reason can be set using the
note = ...meta item (e.g.#[deprecated(note = "Replaced by betterField")]). Thesinceattribute is ignored.
-
There is an alternative syntax for setting a field's description and deprecation reason in the
graphql_object!andgraphql_interface!macros.To deprecate a graphql field:
// Original syntax for setting deprecation reason field deprecated "Reason" my_field() -> { ... } // New alternative syntax for deprecation reason. #[deprecated(note = "Reason")] field my_field() -> { ... } // You can now also deprecate without a reason. #[deprecated] field my_field() -> { ... }
To set the description of a graphql field:
// Original syntax for field descriptions field my_field() as "Description" -> { ... } // Original syntax for argument descriptions field my_field( floops: i32 as "The number of starfish to be returned. \ Can't be more than 100.", ) -> { ... } // New alternative syntax for field descriptions /// Description field my_field() -> { ... } // New alternative syntax for argument descriptions field my_field( /// The number of starfish to be returned. /// Can't be more than 100. arg: i32, ) -> { ... } // You can also use raw strings and const &'static str. // // Multiple docstrings will be collapsed into a single // description separated by newlines. /// This is my field. /// /// Make sure not to filtz the bitlet. /// Flitzing without a bitlet has undefined behaviour. /// #[doc = my_consts::ADDED_IN_VERSION_XYZ] field my_field() -> { ... }
[0.10.0] 2018-09-13
Changes
-
Changed serialization of
NaiveDatewhen using the optionalchronossupport.Note: while this is not a Rust breaking change, if you relied on the serialization format (perhaps by storing serialized data in a database or making asumptions in your client code written in another language) it could be a breaking change for your application.
-
The
GraphQLObject,GraphQLInputObject, andGraphQLEnumcustom derives will reject invalid names at compile time. -
Large integers (> signed 32bit) are now deserialized as floats. Previously, they produced an "integer out of range" error. For languages that do not have a distinction between integer and floating point types (such as javascript), this meant large whole floating point values could not be decoded (because they were represented without a fractional value such as
.0). -
The
GraphQLObject,GraphQLInputObject, andGraphQLEnumcustom derives now parse doc strings and use them as descriptions. This behavior can be overridden by using an explicit GraphQLdescriptionannotation such as#[graphql(description = "my description")]. View documentation. -
Introduced
IntoFieldErrortrait to allow custom error handling i.e. custom result type. The error type must implement this trait resolving the errors intoFieldError. View documentation. -
GraphQLTypeandToInputValueare now implemented for Arc -
Error responses no longer have a data field, instead, error details are stored in the extensions field
Note: while this is a breaking change, it is a necessary one to better align with the latest GraphQL June 2018 specification, which defines the reserved extensions field for error details. View documentation.
-
The
GraphQLObjectandGraphQLInputObjectcustom derives now support lifetime annotations. -
When using the
GraphQLObjectcustom derive, fields can now be omitted by annotating the field with#[graphql(skip)]. View documentation. -
Due to newer dependencies, the oldest Rust version supported is now 1.22.0
[0.9.2] 2018-01-13
Changes
__typename for unions
The __typename query meta-field now works on unions.
Debug impls.
http::GraphQLRequest now implements Debug.
[0.9.0] 2017-12-03
Changes
This is the first release in a long time.
Quite a few changes have accumulated since 0.8.1, including multiple breaking
changes.
Custom derive & macros
Juniper has gained custom derive implementations for input objects, objects and enums.
#[derive(GraphQLInputObject)]#[derive(GraphQLEnum)]#[derive(GraphQLObject)]
The graphql_enum! and graphql_input_object! macros did not provide any more
benefits, so they have been removed!
All functionality is now covered by custom derive.
Check the docs to find out more.
Web framework integrations - Iron & Rocket
The iron and rocket integrations were removed from the main crate, and are now available via the juniper_iron and juniper_rocket crates.
FieldError rewrite (custom data)
The FieldError type now supports custom data with the Value type from
serde_json. Use this to populate the data field in returned errors.
This also means that try! and ? now work in resolvers, which is quite nice.
Also, the ResultExt extension and the jtry! macro were removed, since they
are redundant now!
Dynamic Schemas
Juniper has gained support for dynamic schemas, thanks to @srijs.
That also means the type of RootNode has changed to include a lifetime.
The repository was restructured to a multi crate workspace to enable several new features like custom_derive and an extracted parser.
##66
Data Type Integrations
Integrations with multiple popular crates was added to make working with them easier.
- uuid
- url
- chrono
Field Order
To better comply with the specification, order of requested fields is now preserved.
[#82](#82
From/ToInputValue
The ::from and ::to methods in From/ToInputValue were renamed to
from/to_input_value() to not conflict with other methods.
Other changes
- Several small performance improvements
- Use fnv hash map for better performance
Contributors
A big shoutout to the many contributors for this version, sorted alphabetically.
- Cameron Eldridge mailto:cameldridge+git@gmail.com
- Christian Legnitto mailto:christian@legnitto.com
- Jacob Haslehurst mailto:jacob@haslehurst.net
- Jane Keibler mailto:wanderingelf14@gmail.com
- Magnus Hallin mailto:mhallin@fastmail.com
- rushmorem mailto:rushmore@webenchanter.com
- Rushmore Mushambi mailto:rushmore@webenchanter.com
- Sagie Gur-Ari mailto:sagiegurari@gmail.com
- Sam Rijs mailto:srijs@airpost.net
- Stanko Krtalić mailto:stanko.krtalic@gmail.com
- theduke mailto:chris@theduke.at
- thomas-jeepe mailto:penguinSoccer@outlook.com
0.8.1 – 2017-06-15
Tiny release to fix broken crate metadata on crates.io.
0.8.0 – 2017-06-15
Breaking changes
-
To better comply with the specification, and to avoid weird bugs with very large positive or negative integers, support for
i64has been completely dropped and replaced withi32.i64is no longer a valid GraphQL type in Juniper, andInputValue/Valuecan only represent 32 bit integers.If an incoming integer is out of range for a 32 bit signed integer type, an error will be returned to the client. (#52, #49)
-
Serde has been updated to 1.0. If your application depends on an older version, you will need to first update your application before you can upgrade to a more recent Juniper. (#43)
-
rustc_serializesupport has been dropped since this library is now deprecated. (#51)
New features
- A new
rocket-handlersfeature now includes some tools to use the Rocket framework. A simple example has been added to the examples folder.
Bugfixes
- A panic in the parser has been replaced with a proper error (#44)
0.7.0 – 2017-02-26
Breaking changes
- The
iron-handlersfeature now depends on Iron 0.5 (#30). Because of this, support for Rust 1.12 has been dropped. It might still work if you're not using the Iron integrations feature, however.
New features
- Input objects defined by the
graphql_input_object!can now be used as default values to field arguments and other input object fields.
0.6.3 – 2017-02-19
New features
- Add support for default values on input object fields (#28)
0.6.2 – 2017-02-05
New features
- The
nullliteral is now supported in the GraphQL language. (#26) - Rustc-serialize is now optional, but enabled by default. If you only want Serde support, include Juniper without default features and enable Serde. (#12)
- The built-in
IDtype now has a public constructor and derives a few traits (Clone,Debug,Eq,PartialEq,From<String>,Deref<Target=str>). (#19) - Juniper is now built and tested against all Rust compilers since version 1.12.1.
Minor breaking change
- Serde has been updated to 0.9. (#25)
Bugfixes
- The built-in GraphiQL handler had a bug in variable serialization. (#16)
- The example should now build and run without problems on Windows. (#15)
- Object types now properly implement
__typename. (#22) - String variables are now properly parsed into GraphQL enums. (#17)
0.6.1 – 2017-01-06
New features
- Optional Serde support (#8)
Improvements
- The
graphql_input_object!macro can now be used to define input objects as public Rust structs. - GraphiQL in the Iron GraphiQL handler has been updated to 0.8.1 (##11)
Minor breaking changes
Some undocumented but public APIs were changed.
to_snake_casecorrectly renamed toto_camel_case(#9)- JSON serialization of
GraphQLErrorchanged to be more consistent with how other values were serialized (#10).
0.6.0 – 2017-01-02
TL;DR: Many big changes in how context types work and how they
interact with the executor. Not too much to worry about if you're only
using the macros and not deriving GraphQLType directly.
Breaking changes
-
The
executorargument in all resolver methods is now immutable. The executor instead uses interior mutability to store errors in a thread-safe manner.This change could open up for asynchronous or multi-threaded execution: you can today use something like rayon in your resolve methods to let child nodes be concurrently resolved.
How to fix: All field resolvers that looked like
field name(&mut executornow should sayfield name(&executor. -
The context type of
GraphQLTypeis moved to an associated type; meaning it's no longer generic. This only affects people who implement the trait manually, not macro users.This greatly simplifies a lot of code by ensuring that there only can be one
GraphQLTypeimplementation for any given Rust type. However, it has the downside that support for generic contexts previously used in scalars, has been removed. Instead, use the new context conversion features to accomplish the same task.How to fix: Instead of
impl GraphQLType<MyContext> for ..., you useimpl GraphQLType for ... { type Context = MyContext;. -
All context types must derive the
Contextmarker trait. This is part of an overarching change to allow different types to use different contexts.How to fix: If you have written e.g.
graphql_object!(MyType: MyContext ...)you will need to addimpl Context for MyContext {}. Simple as that. -
Registryand all meta type structs now takes one lifetime parameter, which affectsGraphQLType'smetamethod. This only affects people who implement the trait manually.How to fix: Change the type signature of
meta()to readfn meta<'r>(registry: &mut Registry<'r>) -> MetaType<'r>. -
The type builder methods on
Registryno longer return functions taking types or fields. Due to how the borrow checker works with expressions, you will have to split up the instantiation into two statements. This only affects people who implement theGraphQLTypetrait manually.How to fix: Change the contents of your
meta()methods to something like this:fn meta<'r>(registry: &mut Registry<r>) -> MetaType<'r> { let fields = &[ /* your fields ... */ ]; registry.build_object_type::<Self>(fields).into_meta() }
Added
-
Support for different contexts for different types. As GraphQL schemas tend to get large, narrowing down the context type to exactly what a given type needs is great for encapsulation. Similarly, letting different subsystems use different resources thorugh the context is also useful for the same reasons.
Juniper supports two different methods of doing this, depending on your needs: if you have two contexts where one can be converted into the other without any extra knowledge, you can implement the new
FromContexttrait. This is useful if you have multiple crates or modules that all belong to the same GraphQL schema:struct TopContext { db: DatabaseConnection, session: WebSession, current_user: User, } struct ModuleOneContext { db: DatabaseConnection, // This module only requires a database connection } impl Context for TopContext {} impl Context for ModuleOneContext {} impl FromContext<TopContext> for ModuleOneContext { fn from(ctx: &TopContext) -> ModuleOneContext { ModuleOneContext { db: ctx.db.clone() } } } graphql_object!(Query: TopContext |&self| { field item(&executor) -> Item { executor.context().db.get_item() } }); // The `Item` type uses another context type - conversion is automatic graphql_object!(Item: ModuleOneContext |&self| { // ... });
The other way is to manually perform the conversion in a field resolver. This method is preferred when the child context needs extra knowledge than what exists in the parent context:
// Each entity has its own context struct TopContext { entities: HashMap<i32, EntityContext>, db: DatabaseConnection, } struct EntityContext { // fields } impl Context for TopContext {} impl Context for EntityContext {} graphql_object!(Query: TopContext |&self| { // By returning a tuple (&Context, GraphQLType), you can tell the executor // to switch out the context for the returned value. You can wrap the // tuple in Option<>, FieldResult<>, FieldResult<Option<>>, or just return // the tuple without wrapping it. field entity(&executor, key: i32) -> Option<(&EntityContext, Entity)> { executor.context().entities.get(&key) .map(|ctx| (ctx, executor.context().db.get_entity(key))) } }); graphql_object!(Entity: EntityContext |&self| { // ... });
Improvements
- Parser and query execution has now reduced the allocation overhead by reusing as much as possible from the query source and meta type information.
0.5.3 – 2016-12-05
Added
-
jtry!: Helper macro to produceFieldResults from regularResults. Wherever you would be usingtry!in a regular function or method, you can usejtry!in a field resolver:graphql_object(MyType: Database |&self| { field count(&executor) -> FieldResult<i32> { let txn = jtry!(executor.context().transaction()); let count = jtry!(txn.execute("SELECT COUNT(*) FROM user")); Ok(count[0][0]) } });
Changes
-
Relax context type trait requirements for the iron handler: your contexts no longer have to be
Send + Sync. -
RootNodeis nowSendandSyncif both the mutation and query types implementSendandSync.
Bugfixes
returnstatements inside field resolvers no longer cause syntax errors.
0.5.2 – 2016-11-13
Added
- Support for marking fields and enum values deprecated.
input_object!helper macro
Changes
- The included example server now uses the simple Star Wars schema used in query/introspection tests.
Bugfixes
-
The query validators - particularly ones concerned with validation of input data and variables - have been improved significantly. A large number of test cases have been added.
-
Macro syntax stability has also been improved. All syntactical edge cases of the macros have gotten tests to verify their correctness.