Automatically implement interface fields on implementor graphql objects?

[jacobh]

Ideally I'd like to be able to do

pub trait Node {
    fn id(&self) -> &Uuid;
}

pub struct Queue {
    pub id: Uuid,
    pub name: String,
    ...
}
impl Node for Queue {
    fn id(&self) -> &Uuid {
        &self.id
    }
}

graphql_interface!(<'a> &'a Node: Context as "Node" |&self| {
    field id() -> &Uuid {
        self.id()
    }

    instance_resolvers: |&context| { ... }
});

graphql_object!(Queue: Context |&self| {
    interfaces: [&Node]
    field name() -> &str {
        &self.name
    }
});

And get

scalar Uuid

interface Node {
  id: Uuid
}

type Queue implements Node {
  id: Uuid
  name: String
}

Currently you can get an invalid schema if you forget to implement the id field on the Queue object.

Python's Graphene works in this way http://docs.graphene-python.org/en/latest/types/interfaces/

I realise this wouldn't be a very backwards-compatible change

Thoughts?

[mhallin]

Interesting finds!

The fact that you can create an inconsistent schema is very problematic. I guess another way to cause an inconsistency is to have a mismatch between instance_resolvers and interfaces, too. These kinds of issues need to be guarded against; either by designing the API so they are impossible to create, or making sure that creating an invalid schema panics/returns errors.

The other part, automatically implementing interface fields on object types seems convenient. I'm not sure how to do this in the, though. Juniper can not "upcast" an object into an interface in the general case or vice versa - this is why we need the awkward instance_resolvers. If anyone has any ideas here, let me know :)

[nikis05]

@tyranron I would like to help fix this but wouldn't want to interfere with #1072. Are there plans to address this in #1072, should I wait?

[tyranron]

@nikis05 doesn't this work already on the latest master? I believe this should have been fixed by #1009.