Top 40 GraphQL Interview Questions & Answers 2025

GraphQL is a query language for APIs. Key differences from REST: single endpoint (POST /graphql vs multiple endpoints), clients specify exact data shape (no over/under-fetching), strongly typed schema, introspection (self-documenting), real-time via subscriptions. REST: multiple endpoints, server determines response shape, HTTP caching built-in. Use GraphQL for: complex data requirements, multiple clients with different needs, rapid API evolution.

Query: read-only data fetch, can run in parallel, cacheable. Mutation: write operation with side effects, run sequentially by default, should return the modified resource. Subscription: long-lived operation for real-time data via WebSocket. Convention: queries for reads, mutations for writes (even if they also return data), subscriptions for push notifications. Named operations and variables make operations reusable and debuggable.

N+1: fetching a list of N items causes N additional queries for each item's related data. Example: fetch 10 users → 10 queries for each user's posts = 11 queries total. Solution: DataLoader (by Facebook) — batches and caches requests within a single tick. Collect all IDs, fetch once in batch, distribute results. Essential for any GraphQL server with relational data.

GraphQL bypasses HTTP caching (all POST requests). Solutions: (1) Apollo Client normalizes cache by __typename + id (automatic deduplication), (2) Persisted queries (send hash instead of query string, cacheable GET), (3) Response caching with cache-control hints (@cacheControl directive), (4) Field-level caching with DataLoader. For CDN caching: use persisted queries or convert to GET.

Start with types (nouns): type User { id: ID!, name: String!, email: String! }. Query type (reads), Mutation type (writes), Subscription type (real-time). Connections for pagination (Relay spec: edges, nodes, pageInfo). Use input types for mutations. Design schema from client perspective (what do they need?). Keep types cohesive. Use interfaces and unions for polymorphism.

Interface: shared fields between types. type Dog implements Animal { name: String!, breed: String! }. Union: can be multiple types without shared fields. union SearchResult = User | Post | Product. Query union/interface with inline fragments: ... on Dog { breed }. Always include __resolveType in resolver to tell GraphQL which concrete type. Use interfaces for polymorphic types with common fields; unions for unrelated types.

Relay connection spec (recommended): { edges { node cursor } pageInfo { hasNextPage endCursor } }. Cursor-based: after, before, first, last args — stable for real-time data. Offset: skip, limit — simpler but unstable (inserts shift pages). Simple: use first/offset for admin dashboards. Cursor for user-facing infinite scroll. Implement consistently across all list fields. Apollo Client's fetchMore handles cursor pagination.

Resolvers fetch data for each field. Arguments: parent (result from parent resolver), args (field arguments), context (shared across resolvers — auth, db), info (query AST). Resolver chain: root resolver returns object, field resolvers called for each field. Default resolver: returns parent[fieldName]. Context is the right place for: auth user, database connections, DataLoader instances.

Fragments are reusable selections of fields. Prevent duplication across queries. Named fragment: fragment UserFields on User { id name email }. Inline fragment: ... on Dog { breed }. Use inline fragments for union/interface types. Apollo Client uses fragments for cache normalization. Relay uses fragments colocated with components (each component declares its data needs).

Authentication: verify JWT/session in middleware before resolver chain, attach user to context. Authorization: in resolvers (check context.user), with schema directives (@auth, @hasRole), or using libraries like graphql-shield. Field-level auth in resolvers. Avoid mixing auth logic in schema — keep in resolvers or middleware. Never trust client-sent user data; always verify server-side.

Threats: introspection abuse, deeply nested queries (DoS), field deduplication attacks, batching attacks. Protections: (1) Disable introspection in production, (2) Query depth limiting (graphql-depth-limit), (3) Query complexity scoring, (4) Rate limiting per user, (5) Persisted queries only (whitelist), (6) Request timeout, (7) Disable batching or limit batch size. Never trust client-sent query complexity.

Subscriptions enable real-time updates via persistent connections (WebSocket). Client sends subscription query; server pushes updates when events occur. Implementation: Apollo Server uses graphql-ws, pub/sub via Redis or in-memory. Schema: type Subscription { messageAdded(channelId: ID!): Message }. Use for: chat, notifications, live data feeds. Consider WebSocket connection management and authentication.

Schema stitching: manually merge multiple GraphQL schemas into one — complex, brittle. Federation (Apollo): microservices own their schema slice; gateway composes them at runtime. Each service: @key for entity primary key, @external for fields owned by other services, @requires for computed fields. Federation enables teams to develop independently. Prefer federation for microservices architecture.

Apollo Client is the most popular GraphQL client. Features: normalized cache, reactive queries, optimistic updates, query batching, automatic refetch. Normalized cache: flattens response by __typename:id keys, deduplicates shared objects. When a mutation updates a User, all queries showing that user update automatically. InMemoryCache with typePolicies for custom key fields and field merging. Use useQuery and useMutation hooks in React.