Objects and generics

Yet another point where GraphQL and Rust differs is in how generics work. In Rust, almost any type could be generic - that is, take type parameters. In GraphQL, there are only two generic types: lists and non-nullables.

This poses a restriction on what you can expose in GraphQL from Rust: no generic structs can be exposed - all type parameters must be bound. For example, you can not make e.g. Result<T, E> into a GraphQL type, but you can make e.g. Result<User, String> into a GraphQL type.

Let's make a slightly more compact but generic implementation of the last chapter:

#[macro_use] extern crate juniper;

#[derive(GraphQLObject)]
struct ValidationError {
    field: String,
    message: String,
}

struct MutationResult<T>(Result<T, Vec<ValidationError>>);

graphql_object!(MutationResult<User>: () as "UserResult" |&self| {
    field user() -> Option<&User> {
        self.0.as_ref().ok()
    }

    field error() -> Option<&Vec<ValidationError>> {
        self.0.as_ref().err()
    }
});

graphql_object!(MutationResult<ForumPost>: () as "ForumPostResult" |&self| {
    field forum_post() -> Option<&ForumPost> {
        self.0.as_ref().ok()
    }

    field error() -> Option<&Vec<ValidationError>> {
        self.0.as_ref().err()
    }
});

Here, we've made a wrapper around Result and exposed some concrete instantiations of Result<T, E> as distinct GraphQL objects. The reason we needed the wrapper is of Rust's rules for when you can derive a trait - in this case, both Result and Juniper's internal GraphQL trait are from third-party sources.

Because we're using generics, we also need to specify a name for our instantiated types. Even if Juniper could figure out the name, MutationResult<User> wouldn't be a valid GraphQL type name.

results matching ""

    No results matching ""