Is snake_case_fallback_resolvers or fallback_resolvers being used by default implicitly?

[Q-back]

I struggle to find any information about it in documentation.
Does Ariadne use snake_case_fallback_resolvers or fallback_resolvers for all the fields that doesn't have custom (written by user) resolver attached yet?
It's a bit magically that I can bind a resolver to query that returns raw object with parameters written/named in snake_case and it's being mapped to my type object with camelCased fields.

disclaimer: this is pseudo-code, I didn't run it but it bases on my production code

from ariadne import ObjectType, QueryType, make_executable_schema
from graphql import GraphQLResolveInfo

# Schema
schema_definition = """
schema {
    query: Query
}

type Query {
    user: User
}

type Organization {
    name: String
    dailyIncome: Int
    isBigCompany: Boolean
}

type User {
    fullName: String
    organization: Organization
}
"""


# Data
class Organization:
    def __init__(self, name: str, daily_income: int):
        self.name = name
        self.daily_income = daily_income


class User:
    def __init__(self):
        self.full_name = "John Novak"
        self.organization = Organization(name="Empik", daily_income=420)


# Schema binding
query = QueryType()
user = ObjectType("User")


@query.field("user")
def resolve_user_query(obj: None, info: GraphQLResolveInfo) -> User:
    # Issue: How do I know how's returned `User()` resolved? How is it mapped to JSON?
    return User()


@user.field("organization")
def resolve_organization_type(obj: User, info: GraphQLResolveInfo) -> dict:
    return {
        "name": obj.organization.name,
        "dailyIncome": obj.organization.daily_income,
        "isBigCompany": True if obj.organization.name == "Empik" else False,
    }


schema = make_executable_schema(schema_definition, query, user)

🎯 Check out the resolve_user_query function and the comment

[rafalp]

Does Ariadne use snake_case_fallback_resolvers or fallback_resolvers for all the fields that doesn't have custom (written by user) resolver attached yet?

Neither. When there's no resolver set on field on GraphQL schema, query executor falls back to default resolver which (AFAIR) checks if object is dict and then tries either obj.getattr(field_name) or obj.get(field_name). What snake_case_fallback_resolvers and fallback_resolvers do is they scan schema for fields without set resolvers and set custom resolver for them. Ariadne's custom default resolvers are different in behavior than default one provided by graphql-core.

If you pass snake_case_fallback_resolvers before user to make_executable_schema two things will happen:

1. snake_case_fallback_resolvers will see that fields on User in schema don't have resolvers and will set case-converting resolvers for you.
2. user will override resolvers set in 1. with custom ones you've specified via @user.field decorator. It will leave fields without custom resolvers set alone.

Issue: How do I know how's returned User() resolved? How is it mapped to JSON?

GraphQL spec says that resolver functions should be called with return value of parent field's resolver recursively until parent field's return value is scalar.

Consider this schema:

type Query {
  user: User
  version: String
}

type User {
  id: ID!
}

When you query for { version }, query executor will call resolver for version field on Query type. It gets value from this resolver. It also knows from schema that this value is GraphQL scalar, so next thing it does is calls String scalar's serialize method with value returned from version resolver to retrieve json-serializable representation of value. "version": value is then added to the result JSON.

When you query for { user { id } }, query executor calls resolver for user field on Query type. It gets value from this resolver representing user. It knows from schema that user field's value is User type. So now it calls id field's resolver with user value from parent field's resolver as first argument. id field's value is scalar. So it now calls ID scalar's serialize method on id value returned by id field's resolver. It then builds JSON-serializable value for user and returns it to parent execution context so it can be used to build final json-serializable dict.

[Q-back]

GraphQL spec says that resolver functions should be called with return value of parent field's resolver recursively until parent field's return value is scalar.

This explains a lot to me. I think that it should be mentioned somewhere in the docs along with more info about how and when the default resolver jumps into the action. Schema-first approach for python requires a small twist in the way of thinking and it should be clear when the developer should start writing resolvers and when he could possibly stop writing them and leave the work to default resolver.

If I'll have enough free time I could contribute with PR to docs repo (although I can't find one).

Thanks for the great answer I really appreciate it 🙇🏻 .