Relay specification compliance in GraphQL - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ query_result

intermediate

What is the output of this Relay-compliant GraphQL query?

Given a GraphQL schema with a Node interface and a User type implementing it, what will be the output of this query fetching a user by ID with Relay's node field?

GraphQL

query {
  node(id: "VXNlcjox") {
    id
    ... on User {
      name
    }
  }
}

A { "data": { "node": { "id": "VXNlcjox", "name": "Alice" } } }

B { "data": { "node": { "id": "1", "name": "Alice" } } }

C { "data": { "node": null } }

D { "errors": [{ "message": "Field 'node' does not exist" }] }

💡 Hint

Remember that Relay encodes the global ID as a base64 string combining type and ID.

Relay uses a global ID encoded as base64 combining the type and the internal ID. Here, "VXNlcjox" decodes to "User:1", so the node field returns the user with id "VXNlcjox" and name "Alice".

🧠 Conceptual

intermediate

Which Relay specification rule ensures consistent pagination?

Which of the following Relay specification rules is responsible for consistent pagination behavior across different GraphQL connections?

A Queries must use fragments for all fields.

B Every node must have a globally unique <code>id</code> field.

C All connections must implement <code>edges</code> and <code>pageInfo</code> fields.

D Mutations must return a <code>clientMutationId</code>.

💡 Hint

Think about how Relay handles lists and pagination.

Relay requires connections to have edges (list of items with cursors) and pageInfo (pagination info) fields to standardize pagination.

📝 Syntax

advanced

Which GraphQL fragment correctly implements Relay's Node interface?

Select the fragment that correctly queries a Relay Node with its global ID and typename.

GraphQL

fragment NodeFragment on Node {
  id
  __typename
}

A fragment NodeFragment on Node { id __type }

B fragment NodeFragment on Node { id name }

C fragment NodeFragment on Node { __id __typename }

D fragment NodeFragment on Node { id __typename }

💡 Hint

Relay nodes always have an id and __typename.

The Relay Node interface requires the id field and __typename to identify the type. Option D correctly includes both.

❓ optimization

advanced

How to optimize Relay pagination queries to reduce overfetching?

Which approach best optimizes Relay pagination queries to avoid fetching unnecessary data?

A Always fetch all edges without limits to avoid multiple queries.

B Use <code>first</code> or <code>last</code> arguments with a small number and request only needed fields in <code>edges.node</code>.

C Include all possible fields in the <code>node</code> selection to prevent future queries.

D Avoid using <code>pageInfo</code> to reduce query size.

💡 Hint

Think about limiting data and selecting only what you need.

Using first or last limits the number of items fetched, and selecting only necessary fields reduces data size, optimizing performance.

🔧 Debug

expert

Why does this Relay mutation response cause a client error?

A Relay mutation returns this response: { "data": { "updateUser": { "user": { "id": "1", "name": "Bob" } } } } Why does Relay client report an error?

A The <code>id</code> field is not a global ID encoded as base64.

B The mutation response is missing <code>clientMutationId</code>.

C The <code>user</code> field should be named <code>node</code>.

D The response is missing the <code>edges</code> field.

💡 Hint

Relay expects global IDs in mutation responses.

Relay requires all id fields to be globally unique base64-encoded strings. Here, "1" is not encoded, causing client errors.