Default Field Resolution

Not every field needs an explicit resolver.

Suppose a resolver returns:

{
  id: "42",
  name: "Alice",
  email: "alice@example.com"
}

and the schema contains:

type User {
  id: ID!
  name: String!
  email: String!
}

GraphQL implementations commonly provide default field resolution behavior that reads matching properties from the parent object.

Conceptually:

User object
   |
   +-- id    → User.id
   +-- name  → User.name
   +-- email → User.email

Therefore, you often only need to explicitly define a resolver for fields requiring special behavior.

For example, if name is already a property on the returned object, an explicit resolver may be unnecessary.

But if the schema field is:

fullName: String!

while the underlying object contains:

{
  firstName: "Alice",
  lastName: "Johnson"
}

you may need a custom resolver:

const resolvers = {
  User: {
    fullName: (user) => `${user.firstName} ${user.lastName}`
  }
};

This default-resolution behavior helps keep resolver maps concise.

Custom Computed Field

const resolvers = {
  User: {
    fullName: (user) => `${user.firstName} ${user.lastName}`
  }
};

💡 The underlying object does not contain a fullName property, so a custom resolver computes it from firstName and lastName. Fields whose names already correspond to parent object properties can often use default resolution.

Key Takeaways

GraphQL servers commonly provide default field resolution.
Explicit resolvers are useful for computed or transformed fields.
Returning an object with matching properties can reduce resolver boilerplate.

Knowledge Check

When can a GraphQL field often use default resolution instead of a custom resolver?

Default Field Resolution

STAY UPDATED WITH BYTES!