GraphQL interview questions and answers

GraphQL is a query language and runtime for APIs with one endpoint and a typed schema. Clients ask for exactly the fields they need, across related types, in one request, so there is no over- or under-fetching and fewer round trips. REST exposes resources at many URLs with fixed responses and uses HTTP caching naturally. GraphQL moves complexity to the server (resolvers, query cost, caching).

Resolving a list of 50 posts and then each post's author runs 1 query for posts plus 50 for authors. DataLoader collects all the IDs requested in one tick and calls a batch function once (WHERE id IN (...)), then caches results per request, turning N+1 queries into 2.

Queries read data and can run in parallel. Mutations change data and run in order, returning the changed objects. Subscriptions keep a connection open (usually WebSockets or SSE) and push results when events occur, such as new chat messages.

Model types around the domain (Product, Variant, Cart, Order, Customer) with relationships as fields, use connections for lists, input types and payload types for mutations (addToCart(input): AddToCartPayload with userErrors), nullable fields where data can fail, and avoid exposing database structure directly.

Authenticate at the transport layer (token or cookie) and put the user in the context. Authorise in resolvers or a business layer per field or object, with directives or a policy library, so every path to sensitive data is checked, not just top-level queries.

HTTP caching is harder, complex queries can overload the server, the N+1 problem needs DataLoader, file uploads and errors are less standard, monitoring per operation needs tooling, and there is more setup than a simple REST API.

Functions that return the value for each field in the schema: (parent, args, context, info). The root resolvers fetch top-level data; field resolvers compute nested fields from their parent. Context carries per-request things such as the user, DataLoaders and database clients.

Authenticate per request and pass the user in context, authorise in resolvers or a business layer (not only at the gateway), limit query depth and complexity, set timeouts and rate limits, disable introspection or use persisted queries in production if appropriate, and validate inputs.

HTTP caching is harder because requests are POSTs to one URL. Clients such as Apollo and urql keep a normalised cache keyed by type and ID. Servers use DataLoader per request, response caching, cache hints, and persisted queries sent as GET so CDNs can cache them.

Schema-first writes SDL (type User { id: ID! }) and maps resolvers to it; the schema is a readable contract. Code-first builds the schema from code (Pothos, Nexus, TypeGraphQL, NestJS decorators), giving type safety and less duplication. Both produce the same runtime schema.

A way to compose one supergraph from several subgraphs owned by different teams. Each service defines its types and can extend types from others with entity keys; a router (such as Apollo Router) plans and executes queries across services.

Usually you do not version it: add new fields and types freely, mark old ones @deprecated(reason), monitor usage with schema analytics, and remove them once clients stop using them. Breaking changes are checked in CI against the registry.

Input types (input CreateUserInput) define arguments for mutations and queries. They are separate from output types because inputs cannot contain resolvers or interfaces and often have different required fields.

An interface defines common fields that several types implement (interface Node { id: ID! }). A union lists possible types without shared fields (union SearchResult = User | Post). Clients use fragments with ... on Type to select type-specific fields.

They normalise responses by __typename and id into a flat cache, so updating an object in one query updates it everywhere. You may need cache policies for pagination and manual updates after mutations that add or remove items.

Use WebSockets (graphql-ws) or Server-Sent Events, publish events through a shared pub/sub (Redis, Kafka) so any server can deliver them, filter per subscriber, authenticate the connection, and limit the number of subscriptions per client.

Set maximum depth and complexity scores, paginate all lists with maximum page sizes, use timeouts, rate-limit per client by cost rather than requests, and allow only persisted queries for public clients.

Responses can contain both data and an errors array, often with HTTP 200. Use error extensions with codes, return typed error results in unions for expected errors (union CreateUserResult = User | ValidationError), and log unexpected errors without leaking internals.

Offset pagination (limit, offset) is simple. Cursor-based pagination, often the Relay connection spec (edges, node, cursor, pageInfo), stays stable when data changes and suits infinite scrolling.

Reusable sets of fields (fragment UserCard on User { name avatar }) included in queries. They keep components' data needs next to the components (colocation) and avoid repeating field lists.

The ability to query the schema itself (__schema, __type), which powers tools like GraphiQL, code generation and editor completion. Some teams disable it publicly to reduce information exposure.

Annotations prefixed with @ that change execution or schema behaviour: built-in @include(if:), @skip(if:) and @deprecated, and custom schema directives for auth, formatting or caching hints.

The common approach is to upload directly to object storage with a pre-signed URL obtained through a mutation, then send the resulting URL or key in another mutation. Multipart GraphQL uploads exist but complicate servers and CDNs.

All are Node GraphQL servers: Apollo Server integrates with Apollo's platform; GraphQL Yoga is lightweight and standards-focused (Envelop plugins); Mercurius is built for Fastify with high performance. Choice depends on ecosystem and performance needs.

Unit-test resolvers as functions with fake context and data sources, and integration-test the schema by executing operations against the server (executeOperation) with a test database or mocks.

Stitching merges schemas at a gateway that knows how to combine them. Federation lets each subgraph declare its entities and keys with directives, and a router composes them, which scales better across teams.

Tools like GraphQL Code Generator create TypeScript types and typed hooks from the schema and your operations, so queries are type-checked and responses are typed without hand-written interfaces.

Non-null: String! must always have a value. Lists combine: [String!]! is a non-null list of non-null strings. A null in a non-null field propagates the null up to the nearest nullable parent.

Built-in scalars are Int, Float, String, Boolean and ID; custom scalars (DateTime, Email) add validation and serialisation. Enums restrict a field to a fixed set of values.

Track metrics per operation name (latency, errors, request rate), trace resolver timings, log slow and failing operations, and use schema usage analytics to know which fields clients rely on.

1. AOne per resource
2. BOneCorrect answer
3. COne per field
4. DTwo

Why: Usually a single /graphql endpoint.

1. AGraphiQL
2. BPrisma Studio
3. CApollo Client
4. DDataLoaderCorrect answer

Why: DataLoader batches IDs per tick.

1. Afragment
2. Bquery
3. CmutationCorrect answer
4. Dsubscription

Why: Mutations run sequentially.

1. AOnly at the gateway
2. BOnly in the client
3. COnly on top-level queries
4. DIn resolvers or the business layer, per field or objectCorrect answer

Why: Every path to data must be checked.

1. A@deprecated, then removed when unusedCorrect answer
2. BCreate /v2
3. CRename the endpoint
4. DDelete immediately

Why: Monitor usage first.

1. AHTTP caching is harderCorrect answer
2. BNo types
3. COnly works in browsers
4. DNo mutations

Why: Single POST endpoint.

1. Aquery
2. Bmutation
3. CsubscriptionCorrect answer
4. Ddirective

Why: Subscriptions keep a connection open.

1. AList of strings
2. BDeprecated string
3. COptional string
4. DNon-null stringCorrect answer

Why: ! marks non-null.

1. AcontextCorrect answer
2. Binfo
3. Cparent
4. Dargs

Why: Context is built for each request.

1. AMore resolvers
2. BIntrospection
3. CFragments
4. DDepth and complexity limitsCorrect answer

Why: Limit how deep and costly queries can be.

1. AinputCorrect answer
2. Btype
3. Cscalar
4. Denum

Why: Input types.

1. ACan't be queried
2. BHas no shared fieldsCorrect answer
3. CHas more fields
4. DIs faster

Why: Use inline fragments.

1. ABy timestamp
2. BBy __typename and idCorrect answer
3. CBy query string
4. DBy URL

Why: One copy per object.

1. Agraphql-wsCorrect answer
2. Bsocket.io only
3. Cgrpc
4. Dmqtt

Why: The modern standard library.

1. ADepth and complexity limitsCorrect answer
2. BLonger timeouts
3. CRemoving pagination
4. DAllowing introspection

Why: Score queries before running.

1. APage numbers
2. BKeyset only in SQL
3. COffset
4. DRelay cursor connectionsCorrect answer

Why: Relay's connection spec is cursor-based.

1. APersisted queries
2. BFederationCorrect answer
3. CIntrospection
4. DBatching

Why: A router executes queries across subgraphs.

1. AKey
2. BUUID
3. CInt
4. DIDCorrect answer

Why: ID is serialised as a string.

1. AOnly an HTTP 500
2. Bdata and an errors arrayCorrect answer
3. CNothing
4. DAn HTML error page

Why: Partial data can return with errors.

1. A@hide
2. B@omit
3. C@when
4. D@skip(if:)Correct answer

Why: @include is the opposite.

1. AInside a query
2. BVia subscription
3. CPre-signed URL to object storageCorrect answer
4. DBase64 in a mutation

Why: Keeps servers light.

1. ARelay
2. Burql
3. CMercuriusCorrect answer
4. DApollo Server only

Why: High performance.

1. APrettier
2. BESLint
3. Ctsc
4. DGraphQL Code GeneratorCorrect answer

Why: Typed hooks too.

1. AEntities with keys and a routerCorrect answer
2. BDatabase joins
3. CREST calls only
4. DCopying schemas

Why: Each team owns a subgraph.

1. AOperation nameCorrect answer
2. BIP only
3. CField count
4. DHTTP method

Why: One endpoint hides details otherwise.

1. ASplit the server
2. BReuse sets of fieldsCorrect answer
3. CEncrypt queries
4. DPaginate

Why: They also enable colocation in components.

1. AOPTIONS /graphql
2. Bdescribe()
3. C__schema introspectionCorrect answer
4. DSHOW TABLES

Why: Introspection powers IDE tooling.

1. ASubscriptions
2. BLarger payloads
3. CCDN caching and blocking arbitrary queriesCorrect answer
4. DSchema design

Why: Clients send an ID or hash instead of the full query.

1. AA directive
2. BFields only when the result is a UserCorrect answer
3. CAll users
4. DA mutation

Why: An inline fragment.

1. ANodeCorrect answer
2. BEntity
3. CBase
4. DObject

Why: Used by Relay.