Document resolvers

I just learned, completely by accident, one of the most critically useful features of Graphene: resolvers can return anything, even for object resolvers! They don’t have to return instances of graphene.ObjectType. So, this works:

class TestInstance:
    x = 1
    y = 2

class Test(graphene.ObjectType):
    x = graphene.Int()
    y = graphene.Int()

class Query(graphene.ObjectType):
    test = Test()
    def resolve_test(self, info):
        return TestInstance()

While this is hinted at in the ObjectType reference docs, there are no code examples of the pattern, nor documentation of any kind about the behavior of resolver functions. Documentation about this feature, and guidance about nested Objects, should be added.

I’m trying to draft something but I don’t have a lot of time these days so I wanted to file an issue just in case

[jkimbo]

@altaurog yep I’ve come across this issue before with the Node type. The way we worked around it was to create our own custom Relay.Node type and use that everywhere instead. That then gives you the opportunity to define a resolve_type method on the Node interface that can translate your underlying data structure into a Graphene type. E.g:

class RelayNode(relay.Node):
    class Meta:
        name = 'Node'
        description = 'An object with an ID'

    @classmethod
    def resolve_type(cls, instance, info):
        if isinstance(instance, TestInstance):
            return Test

        return cls.resolve_type(instance, info)

[jkimbo]

Got it, but what is the best practice? Is there a rule of thumb which one should I use?

Depends on how your data is modelled really. Using the ObjectType as a container for your data doesn’t provide any benefits really.