60 GraphQL Interview Questions and Answers (2026)

GraphQL is a query language and runtime for APIs where the client specifies exactly what data it needs in a single request against a strongly typed schema. Unlike REST's many fixed endpoints, GraphQL exposes one endpoint whose response shape is driven by the query.

• Client-driven vs server-driven: In REST the server defines each endpoint's response; in GraphQL the client declares the fields it wants and gets exactly that.

• Endpoint model: REST: many URLs (/users/1, /users/1/posts). GraphQL: a single endpoint (often /graphql) handling all operations.

• Strong typing: A schema defines all types and fields, enabling validation, introspection, and tooling before a request runs.

• Operations: Three root types: Query (read), Mutation (write), and Subscription (real-time).

• Tradeoff: REST leans on HTTP caching and simplicity; GraphQL trades that for flexibility and precise fetching.

Over-fetching is getting more data than you need; under-fetching is getting too little, forcing extra requests. GraphQL solves both by letting the client request exactly the fields it wants, traversing relationships in one round trip.

• Over-fetching: A REST /users/1 might return name, address, and bio when the UI only needs the name, wasting bandwidth.

• Under-fetching: One endpoint doesn't give enough, so you call /users/1 then /users/1/posts: the N+1 round-trip problem.

• GraphQL's fix:

  • The client selects precise fields, so no surplus data is returned.

  • Nested selections fetch related resources in a single query, removing extra round trips.

• Caveat: Over-fetching can reappear on the server side (resolvers loading unused DB columns) unless you optimize resolvers and use batching like DataLoader.

Declarative data fetching means the client describes what data it wants, not how to fetch it: you write the shape of the result, and the GraphQL runtime figures out the resolution. This contrasts with imperative fetching where you manually orchestrate multiple endpoint calls and stitch responses together.

• Declarative (what): A single query states the exact fields and relationships needed, mirroring the UI's data requirements.

• Imperative (how): With REST you decide which endpoints to call, in what order, and merge the data by hand.

• Co-location benefit: Components declare their own data needs (e.g. GraphQL fragments), keeping data requirements next to the UI that uses them.

• Result: Less glue code, predictable response shape, and the server optimizes resolution behind the scenes.

In GraphQL all operations go through one endpoint (typically POST /graphql); the operation type and selection set in the request body, not the URL, determine what happens. This centralizes the API behind a single schema but shifts responsibilities like caching and routing into the application layer.

• Pros:

  • One URL to manage: simpler client config and no endpoint sprawl.

  • The schema is the single source of truth, with introspection and consistent tooling.

  • Clients combine multiple resources in one request, reducing round trips.

• Cons:

  • HTTP/CDN caching by URL no longer works; you need client-side normalized or persisted-query caching.

  • Monitoring and rate limiting per operation is harder since everything shares one route.

  • Standard HTTP status semantics blur: most responses return 200 with errors in the body.

A GraphQL schema is the strongly typed definition of every type, field, and operation the API supports, written in the Schema Definition Language (SDL). It's a 'contract' because it precisely specifies what the client can ask for and what the server promises to return, so both sides can develop independently against the same agreement.

• What it contains: Object types, scalars, enums, input types, and the root Query/Mutation/Subscription entry points.

• Why it's a contract:

  • Frontend knows exactly which fields and types exist without asking backend.

  • Backend knows the precise shape it must resolve.

  • Queries are validated against it before execution, catching errors early.

• Enables tooling: Introspection powers autocomplete, type generation, and docs (e.g. GraphiQL).

• Safe evolution: Additive changes are non-breaking; schema diffing tools can flag breaking changes against the contract.

GraphQL is strongly typed: every field resolves to a type, which is either a scalar (a concrete leaf value) or an object type (a structured node with its own fields you can select further).

• Scalar types:

  • Leaf values that cannot be sub-selected: Int, String, custom scalars, etc.

  • A query path ends at a scalar.

• Object types:

  • Composite types with named fields, e.g. type User { id: ID! name: String }.

  • You must select sub-fields on them; you can't query an object type without specifying which fields you want.

• How they combine:

  • Object fields can point to other object types, building the graph; every traversal must bottom out at scalars.

  • Other type kinds exist too (Enum, Interface, Union, Input), but scalar vs object is the core leaf-vs-node distinction.

The Schema Definition Language is GraphQL's human-readable, language-agnostic syntax for describing the schema: the types, fields, and operations that form the contract between client and server.

• It is the contract:

  • Defines every type, field, argument, and the root operations clients may call.

  • Both frontend and backend agree on this single document.

• It powers tooling:

  • Drives introspection, validation, autocomplete, docs, and codegen.

  • Queries are validated against the SDL before execution.

• It is implementation-independent:

  • The same SDL can back a server written in any language; resolvers supply the behavior behind it.

  • In code-first setups the SDL is generated rather than handwritten, but it still serves as the published contract.

The root operation types are the three entry points into the schema: Query, Mutation, and Subscription. Every operation a client sends starts at one of these root types, which is where graph traversal begins.

• Query (read): Fetches data; expected to be side-effect free and its fields may resolve in parallel.

• Mutation (write): Changes data; top-level fields execute serially, one after another, to keep writes predictable.

• Subscription (stream): Maintains a long-lived connection (often WebSockets) and pushes events to the client over time.

• How they're wired:

  • They're just object types with a special role; only Query is mandatory.

  • You declare them via the schema { query: ... mutation: ... } block (defaults to those names).

An enum is a scalar-like type restricted to a fixed, predefined set of named values. You use it when a field can only legally be one of a small, known list of options.

• What they give you:

  • Schema-level validation: an invalid value is rejected before a resolver runs.

  • Self-documenting, introspectable options that tools can autocomplete.

• When to use:

  • Fixed sets like Status (ACTIVE, INACTIVE), roles, sort directions, or categories.

  • Prefer over free-form String whenever the domain is closed and known.

• Details:

  • Values are serialized as their names (e.g. "ACTIVE"); servers can map them to internal values (ints, constants).

  • Adding values is generally safe; removing or renaming them is breaking.

The ! modifier marks a value as non-null (it can never be null), while [] marks a value as a list. They are independent and combine positionally: the ! can apply to the list itself, to its elements, or to both.

• Non-null modifier !:

  • A field of type String! guarantees a value is always returned: returning null is a runtime error.

  • On arguments/input fields it means the value is required.

• List modifier []: [String] is a nullable list of nullable strings.

• How they combine (read inside-out):

  • [String!]: list may be null, but no element may be null.

  • [String]!: list itself can't be null, but it may contain null elements (or be empty).

  • [String!]!: list is non-null AND every element is non-null.

• Practical caution: A non-null field that resolves to null propagates the error up to the nearest nullable parent, so overusing ! can blank out large response sections.

A fragment is a named, reusable set of fields on a given type that you can spread into multiple queries. You use one whenever several queries (or several components) need the same selection, keeping field sets consistent and maintainable.

• What it is: Defined with fragment Name on Type { ... } and spread with ...Name.

• Maintainability benefits:

  • Single source of truth: change the fields once and every query that spreads it updates.

  • Colocation: in frameworks like Relay/Apollo, each UI component declares its own fragment, so a component owns exactly the data it renders.

• Performance benefits:

  • Enables fragment-based data masking and precise cache normalization: components only re-render when their own fields change.

  • Helps avoid over- and under-fetching by composing exactly the needed fields.

• Inline fragments (... on Type) are a related variant used to select fields conditionally on interfaces/unions.

They are the three GraphQL operation types: Query reads data, Mutation writes data (and may return the result), and Subscription streams data over a long-lived connection in response to server-side events.

• Query: Read-only fetch; root fields execute in parallel and it's safe to cache.

• Mutation:

  • Used to create/update/delete; top-level fields execute serially so writes don't race.

  • Conventionally returns the affected data so the client can update its cache.

• Subscription:

  • Long-lived stream (typically over WebSockets) that pushes a new result each time an event fires (e.g. a new message).

  • Used for real-time updates, not request/response.

• All three are defined as root types in the schema (type Query, type Mutation, type Subscription); only Query is mandatory.

Variables are typed, named placeholders declared in the operation signature and supplied separately as a JSON variables map, instead of hard-coding dynamic values into the query string. They keep the query static and reusable.

• How they work: Declared in the operation: query GetUser($id: ID!), referenced as user(id: $id), and passed in a separate variables object.

• Why preferred over inlining:

  • Reuse and caching: the query string stays identical across calls, so clients and servers can cache/persist it by hash.

  • Safety: the server validates the variable's type and applies non-null/required rules; values aren't string-concatenated, avoiding injection-style bugs.

  • Clarity: no manual escaping of strings, enums, or complex input objects.

Aliases let you rename a field in the response by prefixing it with aliasName:. They're needed whenever a single response would otherwise have key collisions, most commonly when querying the same field more than once with different arguments.

• The core problem they solve: Response keys default to the field name, so requesting user(id: 1) and user(id: 2) together would collide; aliases give each its own key.

• Other uses:

  • Reshaping the response to match what the frontend expects (e.g. renaming name to title).

  • Disambiguating the same field fetched with different arguments or in different fragments.

A named operation gives the operation an explicit name (and usually a type keyword), while an anonymous operation uses the shorthand form with no name. Functionally they fetch the same data, but named operations are required and strongly preferred in real applications.

• Anonymous operation:

  • Shorthand like { user { name } } with no operation type or name.

  • Only valid when the document contains a single operation, and it cannot declare variables.

• Named operation: Written as query GetUser { ... }; the name is mandatory if a document holds multiple operations.

• Why prefer names:

  • Better debugging, logging, and tracing (the name shows up in server metrics and dev tools).

  • Required for declaring variables and for persisted/saved queries.

A resolver is a function that produces the value for a single field in the schema. The engine calls one per field as it walks the query, and each resolver receives four standard arguments that give it everything it needs to compute its value.

• The four arguments (in order):

  1. parent (also called root or source): the result of the parent field's resolver, used to derive this field.

  2. args: the arguments passed to the field in the query (e.g. id in user(id: 5)).

  3. context: per-request shared state (authenticated user, db connections, dataloaders).

  4. info: metadata about the execution (the AST, the requested field name, the path, schema details).

• Key behaviors:

  • A resolver may return a value or a Promise; the engine awaits it before resolving children.

  • The return value becomes the parent for nested resolvers.

Both Interface and Union are abstract types that let a field return one of several object types, but an interface enforces shared fields across implementers, while a union groups unrelated types with no common fields. Choose an interface when the types share structure; choose a union when they don't.

• Interface:

  • Defines a set of fields that every implementing type must include (e.g. a Node with an id).

  • Clients can query the shared fields directly without inline fragments.

• Union:

  • A set of distinct object types with no required common fields (e.g. SearchResult = User | Post | Comment).

  • Clients must use inline fragments (... on Type) to select fields per type.

• How to choose:

  • Shared fields and an "is-a" relationship: use an interface.

  • Heterogeneous results with nothing in common (like search): use a union.

• Common to both: Both need a way to resolve the concrete type at runtime (e.g. __resolveType) so the server knows which type was returned.

Scalars are the leaf types that hold concrete primitive values (the points where a query stops branching). You define a custom scalar when a value needs validation, serialization, or semantics the built-ins don't capture.

• Built-in scalars: Int, Float, String, Boolean, and ID (a serialized-as-string unique identifier).

• Why custom scalars:

  • To represent domain values like DateTime, Email, URL, or JSON with proper meaning.

  • They centralize validation and (de)serialization at the type boundary instead of in every resolver.

• How they work: You implement three functions: serialize (output), parseValue (variables), and parseLiteral (inline literals).

• Caveat: clients don't know a custom scalar's shape from introspection, so document its format clearly.

Input types are a dedicated kind of type used for arguments (especially mutation payloads). GraphQL forbids using output object types as arguments because output types can contain fields that make no sense as input, like resolved relationships, interfaces, or unions.

• Declared with input, not type: Fields may only be scalars, enums, or other input types: no resolvers, no circular object references, no interfaces/unions.

• Why output types can't be reused:

  • An output User might expose computed fields or related objects that a client can't meaningfully send as input.

  • Inputs must be plain serializable data, so the language separates the two concepts entirely.

• Practical benefits:

  • Bundling many args into one input keeps mutation signatures clean and evolvable.

  • Lets you reuse and version argument shapes across operations.

Introspection is GraphQL's built-in ability to query the schema itself, using meta-fields like __schema and __type, to discover all types, fields, and arguments at runtime. It powers tooling but is often disabled in production to reduce the API's exposed surface.

• What it is: A query against reserved fields (__schema, __type, __typename) returns the full type system as data.

• Why it is useful: Powers GraphiQL/Apollo Sandbox autocomplete and docs, code generation, and schema validation/diffing in CI.

• Why disable in production:

  • It hands attackers a full map of the API, easing discovery of sensitive or experimental fields.

  • It is security-through-reduced-exposure, not real authorization: still enforce auth on every field.

• Pragmatic note: Many teams keep it on behind auth or only in staging, and ship a published schema artifact to trusted consumers instead.

Directives are annotations prefixed with @ that attach behavior to schema definitions or query execution. The built-in ones let you mark fields as deprecated and conditionally include or skip parts of a query without changing the query shape.

• @deprecated (schema directive): Marks a field or enum value as obsolete with an optional reason; tooling surfaces the warning but the field still works.

• @include(if: Boolean) (execution directive): Includes a field/fragment only when the variable is true.

• @skip(if: Boolean) (execution directive): The inverse: omits the field when the condition is true; if both apply, @skip wins.

• How they modify execution: @include/@skip let one query adapt to runtime variables, avoiding multiple query variants for conditional UI.

The N+1 problem occurs when resolving a list triggers one query for the list plus one additional query per item to fetch a related field: 1 + N database hits. DataLoader solves it conceptually by collecting those per-item requests within a tick and dispatching them as a single batched query.

• Why it happens: GraphQL resolvers run per field per object, so a field resolver on each of N items fires its own query independently.

• Example: Fetch 100 posts (1 query), then each post's author resolver hits the DB once: 100 more queries.

• How DataLoader fixes it: Instead of querying immediately, each resolver calls loader.load(id); DataLoader buffers the IDs and runs one batch query (WHERE id IN (...)) per tick.

• Result: 1 + N collapses to 2 queries (the list, then one batch for all relations).

DataLoader is a per-request utility that sits between resolvers and your data source, coalescing many individual loads into batched lookups and caching results so repeated requests for the same key hit the database only once.

• Batching:

  • Calls to load(key) during a single event-loop tick are queued, then handed to your batch function as an array of keys for one query.

  • Your batch function must return results in the same order as the keys it received.

• Caching (memoization): Within the loader's lifetime, a given key is fetched once; later load calls return the cached promise.

• Request-scoped lifecycle: Create a new DataLoader per request so cached data never leaks across users or goes stale between requests.

• Net effect: Eliminates the N+1 explosion and de-duplicates redundant fetches, drastically cutting database round trips.

GraphQL has no native file type, so uploads are handled out-of-band: either via the multipart/form-data spec (GraphQL multipart request) or by uploading directly to storage and passing only a URL/reference through GraphQL.

• The GraphQL multipart request spec:

  • Sends a multipart/form-data POST with three parts: operations (the query/variables JSON), a map linking files to variable paths, and the binary files themselves.

  • Servers expose an Upload scalar; libraries like graphql-upload or Apollo Server integrations wire this up.

• Out-of-band / signed URL approach (often preferred):

  • A mutation returns a pre-signed upload URL (S3, GCS); the client PUTs the file directly to storage, then sends the resulting key back via another mutation.

  • Keeps large binaries off the GraphQL server, scales better, and avoids coupling uploads to the schema.

• Trade-offs:

  • Multipart is convenient but breaks pure-JSON caching/CDN assumptions and complicates batching.

  • Base64-encoding into a string works for tiny files but bloats payloads (~33%) and is rarely advisable.

Pagination in GraphQL is done by exposing list fields that accept paging arguments. The two main models are offset-based (skip N, take M) and cursor-based (Relay Connections), which page relative to a stable pointer rather than a numeric position.

• Offset-based pagination:

  • Uses arguments like limit and offset (or page/pageSize); maps directly to SQL LIMIT/OFFSET.

  • Simple and supports jumping to arbitrary pages, but suffers drift: inserts/deletes shift items, causing skipped or duplicated rows, and large offsets are slow.

• Cursor-based (Relay) pagination:

  • Pages relative to an opaque cursor pointing at a specific record, using first/after (forward) or last/before (backward).

  • Stable under concurrent writes since the cursor anchors to a row, not an index; ideal for infinite scroll.

• Relay Connection shape: Standardizes a edges { node, cursor } list plus pageInfo { hasNextPage, endCursor }, which clients use to fetch the next page.

• Trade-off: cursor pagination can't easily jump to an arbitrary page number, but it's the standard for large, frequently changing datasets.

The key difference is in how top-level (root) fields are resolved: Query root fields are executed in parallel, while Mutation root fields are executed serially, one after another in the order written.

• Queries: parallel: Since reads have no side effects, the engine is free to resolve all root fields concurrently for speed.

• Mutations: serial:

  • The spec guarantees top-level mutation fields run sequentially, so the first write completes before the next begins, preventing race conditions on dependent writes.

  • Example: createUser then updateUser in one operation will run in that order.

• Important nuance: The serial guarantee applies only to root-level fields. Nested/child resolvers under each mutation still run in parallel, just like queries.

Both let you select fields conditionally or reuse selections, but named fragments are reusable, declared selection sets you spread by name, while inline fragments are anonymous and used to select fields based on a concrete type at runtime (on interfaces and unions).

• Named fragments:

  • Declared with fragment X on Type and spread via ...X.

  • Purpose: reuse a selection set across multiple queries or components, reducing duplication.

• Inline fragments:

  • Anonymous, written inline as ... on Type { ... }.

  • Purpose: select type-specific fields when a field returns an interface or union (polymorphic results).

• When to use inline fragments:

  • Resolving abstract types: pick different fields depending on the concrete object type.

  • Often paired with __typename so the client knows which branch matched.

Optimistic UI updates the cache with the expected result of a mutation immediately, before the server responds, so the interface feels instant: if the server later disagrees or errors, the client rolls back to the real value.

• How it works in Apollo:

  • You provide an optimisticResponse shaped like the mutation result.

  • Apollo writes it to the cache temporarily, UI re-renders, then reconciles with the real response.

  • On error, the optimistic write is automatically discarded.

• UX benefits:

  • No perceived latency for actions like likes, toggles, or adding a comment.

  • Feels responsive even on slow networks.

• Caveats:

  • Best for predictable results; avoid when the server computes values you can't guess (e.g. generated IDs, server timestamps).

  • Provide a stable temporary key so rollback works cleanly.

Authentication (who you are) is best handled at the transport/web server layer, while authorization (what you may do) belongs in your business logic, typically the resolver layer or a service the resolver calls. GraphQL itself is unopinionated about both.

• Authentication: at the edge:

  • Validate the token/session in middleware before GraphQL runs (e.g. parse a JWT or cookie in the HTTP layer).

  • Put the resulting user onto the context so every resolver can read it.

• Authorization: at the resolver / business layer:

  • A single GraphQL endpoint exposes many fields with different permissions, so a one URL = one rule model (like REST) doesn't fit.

  • Check permissions per field or per object inside resolvers, ideally delegating to a shared auth/service layer so rules aren't duplicated.

• Why not the data layer alone: The data layer can enforce row-level security as defense in depth, but it lacks GraphQL context (selected fields, query shape) needed for fine-grained rules.

• Practical tools:

  • Schema directives (e.g. @auth(requires: ADMIN)) centralize checks declaratively.

  • Throw an error (e.g. ForbiddenError) to deny; it appears in the errors array while other fields still resolve.

GraphQL handles errors via a top-level errors array in the response, returned alongside whatever data could still be resolved. Over HTTP it usually returns 200 OK because, from the transport's view, the request was received and processed successfully even if individual fields failed; GraphQL errors are application-level, not transport-level.

• Errors live in the response body:

  • A valid response can contain both data and errors: partial success is a first-class outcome.

  • Each error carries message, path (which field failed), locations, and an extensions object for codes/metadata.

• Why 200 OK:

  • One query can touch many resolvers; some succeed, some fail, so a single HTTP status can't represent the result faithfully.

  • HTTP status reflects transport, not business logic: the GraphQL layer reports field-level failures itself.

• Null propagation: A failed field becomes null; if it's non-nullable, the error bubbles up to the nearest nullable parent.

• Exceptions to 200:

  • Transport-level failures (malformed JSON, parse/validation errors, auth at the edge) can legitimately return 400/401.

  • The newer graphql-over-http spec also allows non-200 for some cases, but tooling has long assumed 200.

The context is a per-request object the GraphQL server builds once when a request arrives and passes as the third argument to every resolver in that request. It's the standard place to put shared, request-scoped data like the authenticated user, database connections, and dataloaders.

• How it's created:

  • You provide a context function in server setup that runs once per request, often reading the HTTP request (headers, cookies).

  • Authenticate there (e.g. verify a token) and attach context.user.

• How resolvers use it:

  • Every resolver reads from the same context object, so auth and shared resources don't need re-fetching per field.

  • It's the natural place for authorization checks (if (!context.user) throw ...).

• Why request-scoped matters:

  • Each request gets a fresh context, so data from one user never leaks into another's resolvers.

  • Per-request dataloaders here also enable batching/caching to fix the N+1 problem.

When you don't supply a resolver for a field, GraphQL uses a default resolver: it looks at the parent object returned by the parent field and reads the property with the same name as the field. This is why simple pass-through fields need no code at all.

• The default behavior:

  • For field name, it returns parent.name (in JS reference implementations).

  • If the property is a function, it calls it with the field's args and context.

  • If the property is missing, the field resolves to null (or errors if non-nullable).

• Why it exists: Most object fields just expose properties already on the fetched object, so writing explicit resolvers for each would be tedious boilerplate.

• When you must override it:

  • Computed/derived fields (fullName from first + last).

  • Name mismatches between schema field and data property.

  • Fields requiring a separate fetch (relationships, external services).

Choose subscriptions for true real-time, server-pushed events over a persistent connection; choose SSE for simpler one-way streaming, and polling only for low-frequency or occasional updates where infrastructure simplicity wins.

• Use a subscription when:

  • You need low-latency push of frequent events (chat, live scores, presence) integrated into the GraphQL schema.

  • Clients want to select exactly which fields each event delivers, just like queries.

• Use long polling when:

  • Updates are infrequent and slight latency is fine, or you must work through restrictive proxies/firewalls that block persistent connections.

  • You want the simplest possible stack with no special server.

• Use SSE when:

  • You need server-to-client streaming only (no client-to-server messages) and want automatic reconnection and plain HTTP.

  • GraphQL-over-SSE is increasingly the recommended transport for subscriptions when bidirectional WebSockets aren't required.

• Rule of thumb: High-frequency real-time: subscription; one-way stream: SSE; rare updates or constrained networks: polling.

Subscriptions are the third GraphQL operation type (besides query and mutation) that let the server push results to the client whenever an event occurs, using the same schema and selection-set semantics over a persistent connection.

• What they are:

  • Defined under the Subscription root type; the client picks fields like a query, and gets a stream of results over time rather than a single response.

  • Driven by server-side events (a new message, a status change) typically via pub/sub.

• vs. WebSockets:

  • WebSockets are a raw transport; subscriptions are a higher-level GraphQL feature that often runs over WebSockets but is not the same thing.

  • Subscriptions add typed schema, validation, and field selection on top of whatever transport carries them.

• vs. Polling:

  • Polling repeatedly re-runs a query on a timer: wasteful requests and latency between intervals.

  • Subscriptions push only when data actually changes, giving lower latency and less load.

• When to skip them: For rare updates, polling is simpler and avoids the operational cost of persistent connections and pub/sub infrastructure.

GraphQL's flexibility comes with real costs: HTTP caching is harder, performance can degrade through unbounded queries, and the server complexity rises. For simple, resource-oriented, or cache-heavy APIs, REST is often the better choice.

• Caching is harder: A single POST /graphql endpoint defeats standard HTTP/CDN caching; you need application-level or normalized client caches.

• Performance pitfalls: Deeply nested queries can trigger N+1 database calls; you need DataLoader, query depth/complexity limits, and rate controls.

• Added complexity: Schema design, resolvers, and tooling are upfront overhead for small teams or simple APIs.

• File uploads and binary data: Not native; needs extra specs or a separate REST endpoint.

• Recommend against when: The API is simple/CRUD, you rely heavily on HTTP caching/CDNs, or you serve mostly files: REST is simpler and cheaper.

GraphQL favors continuous, versionless evolution instead of REST-style version numbers: you add new fields and types, and deprecate old ones with the @deprecated directive rather than spinning up /v2. Because clients request only the fields they use, additive changes don't break anyone.

• Why REST needs versions: Endpoints return fixed payloads, so changing a response shape can break clients, forcing /v1, /v2 URLs.

• Why GraphQL avoids it: Clients select fields explicitly, so adding fields never affects existing queries (additive, non-breaking changes).

• Deprecation over removal: Mark stale fields with @deprecated(reason: "..."); tooling warns clients while the field still works.

• Monitoring usage: Field-level analytics show when a deprecated field has no traffic, making safe removal possible.

They are two ways to keep your SDL schema and your runtime resolvers in sync: schema-first writes the SDL by hand as the source of truth, while code-first generates the SDL from typed code (classes/decorators).

• Schema-first:

  • You author .graphql SDL first, then implement resolvers to match it.

  • Pros: the schema is explicit, language-agnostic, and easy for frontend/backend to read as a contract.

  • Cons: SDL and resolvers can drift; you need tooling/codegen to keep types aligned.

• Code-first:

  • You define types in your host language (e.g. Nexus, TypeGraphQL, Strawberry) and the SDL is generated.

  • Pros: single source of truth, full type-safety with the language, refactors and IDE support.

  • Cons: the schema is less obvious at a glance and can feel coupled to one language/framework.

• Key trade-off: Schema-first optimizes for a clear shared contract; code-first optimizes for type-safety and avoiding drift.

In GraphQL fields are nullable by default; you add ! to mark a field non-null. Nullability is a deliberate contract, and making everything non-null can make your API brittle under partial failures.

• How nullability is expressed:

  • String is nullable; String! is non-null.

  • Lists nest it: [String!]! means a non-null list of non-null strings.

• The error-propagation risk:

  • If a non-null field resolves to null (or errors), the null bubbles up to the nearest nullable parent, potentially nulling a whole branch.

  • Marking everything non-null means one failed field can wipe out an entire response.

• Guidance:

  • Use ! for fields you can truly guarantee (e.g. id).

  • Leave fields nullable when they depend on external services, optional data, or could fail independently.

  • Adding ! later is a breaking-safe change; removing it is breaking, so be conservative.

Schema evolution is the practice of changing a GraphQL schema over time while keeping existing clients working. GraphQL favors continuous, additive evolution over API versioning: a change is breaking if it can invalidate a query that previously worked or a response shape a client relied on.

• Safe (backward-compatible) changes:

  • Adding a new type, field, or enum value.

  • Adding a nullable field or an optional (nullable) argument with a default.

• Breaking changes:

  • Removing or renaming a field, type, or enum value still in use.

  • Changing a field's type (e.g. String to Int, or nullable to non-null).

  • Adding a new required (non-null, no default) argument to a field.

  • Making an existing nullable field non-null is fine for output, but tightening an input/argument to non-null is breaking.

• Managing evolution:

  • Deprecate instead of delete: mark fields with @deprecated(reason: "...") and remove only after clients migrate.

  • Use schema checks against real query traffic (e.g. Apollo schema checks) to catch breakage before deploy.

Both compose multiple GraphQL services into one unified schema, but they differ in where the composition logic lives. Schema stitching centralizes glue code in a gateway, while Apollo Federation distributes ownership: each subgraph declares how it extends the graph, and a router composes them. Companies move to federation for clearer team ownership and less brittle, centralized glue.

• Schema Stitching:

  • A gateway merges remote schemas and you manually write resolvers/type-merging config to link them.

  • Glue logic lives at the gateway, so cross-service relationships become a central bottleneck to maintain.

• Apollo Federation:

  • Each subgraph owns parts of types using directives like @key, @external, and @requires.

  • A subgraph can extend a type defined elsewhere; the router resolves entities across services via _entities reference resolvers.

• Why move to federation:

  • Team autonomy: each team owns and deploys its subgraph independently.

  • Declarative composition replaces hand-written stitching glue.

  • Better tooling: managed composition, schema checks, and a single supergraph artifact.

A Backend for Frontend (BFF) is a dedicated server-side layer tailored to the needs of one specific client (web, iOS, Android), shielding it from the shape and chatter of downstream services. GraphQL fits naturally because a single GraphQL endpoint can aggregate many backends and let each client request exactly the fields it needs.

• The problem BFF solves:

  • Different clients need different data shapes; a generic API forces over-fetching or many round trips.

  • A BFF owns aggregation, auth, and shaping for its client, keeping the frontend thin.

• Where GraphQL fits:

  • One GraphQL endpoint aggregates REST/gRPC/other services behind resolvers.

  • Clients select precise fields, so a GraphQL BFF can serve multiple frontends with one flexible schema.

• Trade-off / nuance:

  • GraphQL's flexibility can reduce the need for many per-client BFFs, but a per-client BFF can still help when clients diverge sharply.

  • In federation, the router often plays the aggregation role a BFF would otherwise fill.

A supergraph is the single, unified GraphQL schema that results from composing many independent subgraphs (one per microservice) into one queryable graph. Clients see and query one schema, while behind the scenes each service owns its slice of types and fields.

• Composition:

  • Subgraphs are the per-service schemas; the supergraph is the composed result plus routing metadata.

  • Types can be split across services: a User may have profile fields from one service and order fields from another.

• How queries resolve:

  • The router builds a query plan, fetches each part from the owning subgraph, and stitches the result together.

  • Entities are linked across subgraphs via keys (@key).

• Why it matters: Clients get one coherent API; teams keep independent deployment and ownership of their microservice's subgraph.

Composite schemas are schemas built by combining multiple sources into one graph, including sources that aren't natively GraphQL. The key idea is that resolvers (or a connector layer) translate GraphQL fields into calls against REST APIs, databases, gRPC services, or other backends, so the non-GraphQL source appears as ordinary types and fields.

• The graph is a façade:

  • GraphQL defines the type system; resolvers map each field to whatever backend produces its data.

  • A field can call a REST endpoint, query SQL, or read a cache: the client never knows the difference.

• Integrating non-GraphQL sources:

  • Wrap a REST API: a resolver fetches JSON and shapes it to the GraphQL type.

  • Declarative connectors (e.g. Apollo Connectors with @connect) map REST endpoints to schema fields without hand-written resolver code.

• Why it's useful: Lets you incrementally adopt GraphQL over legacy systems and unify heterogeneous data under one schema and one query language.

A gateway (in modern Apollo Federation, the router) is the single entry point of a federated graph: it exposes the composed supergraph, plans how to satisfy each incoming query across subgraphs, executes those sub-requests, and assembles the final response. Clients talk only to it.

• Core responsibilities:

  • Query planning: break a client query into steps targeting the right subgraphs.

  • Execution & resolution of entity references across subgraphs.

  • Response composition: merge partial results into one shape matching the query.

• Cross-cutting concerns: Auth, rate limiting, caching, tracing, and metrics live at the router.

• Gateway vs. router: The original @apollo/gateway runs in Node.js; the Apollo Router is a faster Rust replacement with the same role.

• Trade-off: It is a critical shared component, so its performance and availability bound the whole graph.