GraphQL Interview Questions and Answers

Resolvers run per field. If a list resolver returns N items and a child field resolver loads related data one item at a time, you get one query for the list plus N queries for the children.

query { orders { id customer { name } } }

Naively this runs one query for orders and one per order to fetch each customer. The fix is batching within a request: DataLoader collects all keys requested during a tick and issues a single WHERE id IN (...) query, then dispatches the results back to each resolver.

const customerLoader = new DataLoader(ids =>
  db.customers.findByIds(ids)
);

DataLoader also caches per request, preventing duplicate loads. Alternatives include join-based root resolvers, persisted query plans, or a query planner that fetches the whole subtree. Always scope the loader to the request, not the process, to avoid stale data across users.

A resolver has the signature (parent, args, context, info):

• parent (also root/value): the object returned by the parent resolver.
• args: the arguments supplied to this field, already coerced to schema types.
• context: a per-request object for shared state such as the authenticated user, database clients and DataLoaders. It is created once per request and is where authorization and tracing are usually wired.
• info: metadata about the execution, including the field name, return type, path and query AST, useful for logging and projection optimization.

const resolvers = {
  Query: {
    user: (_, { id }, ctx) => ctx.db.user.findById(id),
  },
};

For a default-returning field you can often omit the resolver. Keep resolvers thin: validate and authorize, delegate to services, and avoid embedding business logic that cannot be reused or unit-tested without a GraphQL layer.

Two options:

• Offset/limit: orders(offset: 40, limit: 20). Easy to implement but unstable when items are inserted or removed and slow at large offsets.
• Cursor-based connections following the Relay spec: orders(first: 20, after: "cursor") returning edges, node, cursor and pageInfo with hasNextPage and endCursor.

type OrderConnection {
  edges: [OrderEdge!]!
  pageInfo: PageInfo!
}

Cursors encode a stable, indexed sort key so pages do not skip or repeat items under concurrent writes. Always cap first and last to protect the server, make the connection a reusable pattern across fields, and document the sort order. Cursor pagination is more code but is the standard for feeds and anything that changes frequently.

GraphQL usually returns HTTP 200 with a JSON body containing data and/or errors, because a single operation can partially succeed across fields.

{
  "data": { "user": { "name": "Ada", "email": null } },
  "errors": [
    { "message": "Email not visible",
      "path": ["user", "email"],
      "extensions": { "code": "FORBIDDEN" } }
  ]
}

Each error may include path, locations and extensions. Use extensions.code for stable, machine-readable categories, and avoid leaking internal messages. Null bubbling matters: if a non-null field resolves to null, the null propagates up to the nearest nullable ancestor, which can wipe out large parts of data.

For transport failures such as authentication, returning a 401 is still appropriate. Many teams adopt an explicit result union for mutations so domain errors are typed instead of hidden in the errors array.

Authorization belongs in the server layer, never in the client query. Because clients can request any combination of fields, enforce rules at the field and object level, not only at the endpoint.

Common approaches:

• Check permissions in the context when building it, then re-check per resolver for sensitive fields.
• Use schema directives such as @auth(requires: ADMIN) applied to fields or types, backed by middleware that wraps resolvers.
• Return typed errors or null for fields the caller cannot see, and never expose existence of unauthorized data.

type Query {
  salary: Int @auth(requires: HR)
}

Beware of leaking data through error messages, counts or relation traversal. Centralize policy in a reusable authorization service, test it per field, and audit new fields because introspection and tooling make the schema map easy to discover. Rate limiting and query cost analysis complement authorization but do not replace it.