Deserialize GraphQL enum into user defined Rust enum

[jakmeier]

Hi,

I have been using this crate for more than a year in the client of a hobby project browser game. Love this crate, thanks a bunch for the great work!

One thing has been bothering me for a while. In the code generated for a query, is it possible to define an existing Rust enum to use for deserialization instead of generating a new one? I'm thinking of something akin to custom scalars, where any Rust object with the same name as the GraphQL type defined in the schema can be used, as long as it implements Deserialize.

As far as I can tell, nothing like that is supported today, is that correct? I'm happy to dig into the code and see if I could come up with a PR as an implementation suggestion, if the maintainers of this crate think it would be a worthwhile feature to add.

Motivation

My motivation for this is the following.

I have several Rust enums defined in a crate that I import in the client and the server. The Rust enums are simple C-style enumerations without fields, hence I map them to GraphQL enums.

The server uses Juniper to generate and serve a GraphQL interface. Using the graphql_client_cli, I create a schema.json from a running backend instance. Then I generate the code for the queries. This generates new enum types for each query.

So far so good. But I want to use the same enum type in the client as used by the backend. Thus, I have to manually translate from the generate enum back to the original enum type. I have to do this for every query where the enum is used. When I add a enum variant, I have to change the translation code for all queries.

Being able to specify to deserialize into my Rust enum directly would save me a lot of boiler-plate code.

Example

Shared Rust enum used by client and server:

#[derive(Clone, Copy, Serialize, Deserialize)]
#[cfg_attr(feature = "backend", derive(juniper::GraphQLEnum))]
pub enum BuildingType {
    Tree,
    Temple,
}

Schema generated by Juniper:

{
          "description": null,
          "enumValues": [
            {
              "deprecationReason": null,
              "description": null,
              "isDeprecated": false,
              "name": "TREE"
            },
            {
              "deprecationReason": null,
              "description": null,
              "isDeprecated": false,
              "name": "TEMPLE"
            }
          ],
          "fields": null,
          "inputFields": null,
          "interfaces": null,
          "kind": "ENUM",
          "name": "BuildingType",
          "possibleTypes": null
        },

Query:

query BuildingsQuery($village_id: Int!) {
  village(villageId: $village_id) {
    buildings {
      id
      buildingType
    }
  }
}

Manual translation I currently need to do:

impl Into<BuildingType> for &buildings_query::BuildingType {
    fn into(self) -> BuildingType {
        match self {
            buildings_query::BuildingType::TREE => BuildingType::Tree,
            buildings_query::BuildingType::TEMPLE => BuildingType::Temple,
            buildings_query::BuildingType::Other(_) => panic!("Unexpected BuildingType"),
        }
    }
}

[tomhoule]

Hi @jakmeier — thanks for the kind words. Yes, I think that feature would make a lot of sense. How do you imagine that option would look from a library user perspective? I can imagine it could be done with annotations on the derive, something like extern_enums("BuildingType", "SomethingElse"). Also note that we wouldn't be able to validate that the variants match in the macro, so we would trust the user tthat the enums actually match.

[jakmeier]

Glad to hear the feature makes sense to you in principal. I was also thinking about an annotation on the derive, that's where I would look for it as a library user. extern_enums is a good naming for it, I think.

The point about variant validation is interesting, I haven't really thought about it before. Personally, I feel like that should be okay. If someone uses externally defined enums, they have to accept the loss of compile-time validation against the schema. And it's the users responsiblity to ensure serialization and deserialization match. It sounds quite reasonable to me.

Also related to the variant validation, I thought about the catch-all behaviour that Other currently provides. I know I would want to keep it because client and server version can go out of sync. I plan to handle this case on the user side with #[serde(default)] on a new variant on the external enum. This way the graphql-client can fully rely on Deserialze but I as a user can still have clean error handling.

[jakmeier]

#359 PR is ready :-) There are some CI errors but only those that are also on the master. Locally, everything as specified in contributors guide runs through on my machine.

[tomhoule]

Closing this issue, since the PR is merged :) It will be released with 0.10.0 (soon)