Automatic Delegation of Nested Field Resolvers to Root Query Resolvers

[lrivera]

Feature Request: Automatic Delegation of Nested Field Resolvers to Root Query Resolvers

Description

Currently, when defining a nested field (e.g., the creator field in a type like EstablishmentType), you must explicitly specify a resolver for that field—even if a resolver for the same field is already defined in the root query. This forces developers to duplicate logic or centralize it in helper functions to maintain consistency.

Current Behavior

• Each nested field is resolved independently using its own resolver (or the default resolver, which simply looks up the corresponding property on the source object).
• There is no built-in mechanism that automatically delegates the resolution of a nested field (e.g., creator in EstablishmentType) to the resolver defined in the root query for that field.

Expected Behavior

• The library should automatically recognize, based on the field name, that if a resolver for creator is defined in the root query, it should be invoked automatically when resolving the nested creator field in other types.
• This behavior would eliminate the need to manually specify the same resolver logic in multiple places, reducing duplication and ensuring consistency.

Proposed Implementation

• Global Configuration Option: Introduce a configuration flag in the library that enables automatic delegation of nested field resolvers to their corresponding root query resolvers.
• Resolver Mapping: When resolving a nested field, the library could look up a global mapping of resolvers (populated from the root query) and, if a matching resolver exists, delegate the resolution to it instead of using the default behavior.
• Override Capability: Allow this behavior to be overridden by explicitly defining a custom resolver on a nested field when necessary.

Example

Assume you have the following root query resolver for creator:

"creator": &graphql.Field{
	Type: UserType,
	Args: graphql.FieldConfigArgument{
		"id": &graphql.ArgumentConfig{Type: graphql.NewNonNull(graphql.ID)},
	},
	Resolve: func(p graphql.ResolveParams) (interface{}, error) {
		// Logic to retrieve the user by their ID.
	},
},

2. Nested Field in EstablishmentType

Now, consider an EstablishmentType that has a nested creator field. With the proposed feature, you would define the type without specifying an explicit resolver for creator:

var EstablishmentType = graphql.NewObject(graphql.ObjectConfig{
    Name: "Establishment",
    Fields: graphql.Fields{
        "id": &graphql.Field{
            Type: graphql.ID,
        },
        "name": &graphql.Field{
            Type: graphql.String,
        },
        "creator": &graphql.Field{
            Type: UserType,
            // No resolver is specified here; we expect the system to automatically delegate
            // to the root query's "creator" resolver.
        },
    },
})

3. Expected Query Behavior

When a query like the following is executed:

graphql
{
  establishment(id: "1") {
    id
    name
    creator {
      id
      email
    }
  }
}

[mentatbot]

If you would like me to solve this issue, either tag me in a comment or check this box:

• Solve Issue

_{You can disable automatic comments on my settings page}

[srauba]

We manage to solve the duplication problem by creating fields with injected resolvers. Fx helps us with DI. Instead of manually setting the resolver for every creator field, you can inject resolver function

func NewCreatorField(r *UserResolver) *graphql.Field {
    return &graphql.Field{
        Name: "creator",
        Type: UserType,
        Resolve: r.GetCreator,
    }
}

Unlike JS dynamic approach, Go prefers straightforward and explicit definitions