Subgraph definition in GraphQL - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ query_result

intermediate

What is the output of this subgraph query?

Given this subgraph schema and query, what will be the result?

type Product @entity {
  id: ID!
  name: String!
  price: Int!
}

query {
  products {
    id
    name
  }
}

GraphQL

schema {
  query: Query
}

type Query {
  products: [Product!]!
}

type Product @entity {
  id: ID!
  name: String!
  price: Int!
}

query {
  products {
    id
    name
  }
}

A [{"id": "1", "name": "Apple"}, {"id": "2", "name": "Banana"}]

B [{"id": "1", "name": "Apple", "price": 100}, {"id": "2", "name": "Banana", "price": 50}]

C [{"id": "1"}, {"id": "2"}]

D []

💡 Hint

The query only asks for id and name, so price is not included in the output.

The query requests only id and name fields for each product. The subgraph returns all products with those fields. The price field is not requested, so it is not in the output.

📝 Syntax

intermediate

Which option contains a syntax error in subgraph definition?

Identify the option that has a syntax error in the GraphQL subgraph schema definition.

GraphQL

type User @entity {
  id: ID!
  username: String!
  email: String!
}

A

type User @entity {
  id: ID!
  username: String!
  email: String!
}

B

type User @entity {
  id: ID!
  username: String!
  email: String
}

C

type User @entity {
  id: ID!
  username: String!
  email: String!

D

type User @entity {
  id: ID!
  username: String!
  email: String!
  age: Int
}

💡 Hint

Check for missing closing braces or punctuation.

Option C is missing the closing brace '}' at the end of the type definition, causing a syntax error.

❓ optimization

advanced

Which subgraph query is optimized to fetch only needed data?

You want to fetch only the id and title of posts from a subgraph. Which query is optimized?

GraphQL

type Post @entity {
  id: ID!
  title: String!
  content: String!
  author: User!
}

A

query {
  posts {
    id
  }
}

B

query {
  posts {
    id
    title
    content
  }
}

C

query {
  posts {
    id
    author {
      id
    }
  }
}

D

query {
  posts {
    id
    title
  }
}

💡 Hint

Only request the fields you need to reduce data transfer.

Option D requests only id and title, exactly what is needed. Other options request extra fields, making them less optimized.

🔧 Debug

advanced

Why does this subgraph query return an empty list?

Given this subgraph schema and query, why does the query return an empty list?

type Book @entity {
  id: ID!
  title: String!
  author: String!
}

query {
  books(where: {author: "Unknown"}) {
    id
    title
  }
}

GraphQL

type Book @entity {
  id: ID!
  title: String!
  author: String!
}

query {
  books(where: {author: "Unknown"}) {
    id
    title
  }
}

A The query is missing the 'id' field, so no results are returned.

B There are no books with author exactly "Unknown" in the data.

C The 'author' field is not indexed, so filtering is not supported.

D The 'where' filter syntax is invalid and causes the query to fail silently.

💡 Hint

Check if the data contains any matching entries for the filter.

The query returns an empty list because no book has the author field exactly equal to "Unknown". The filter is valid and the query runs correctly.

🧠 Conceptual

expert

What is the main purpose of a subgraph in a GraphQL architecture?

Choose the best explanation for the role of a subgraph in a GraphQL system.

A A subgraph defines a part of the overall schema and data, allowing modular and scalable GraphQL services.

B A subgraph is a client-side cache that stores query results for faster access.

C A subgraph is a database table that stores GraphQL queries and mutations.

D A subgraph is a tool to convert REST APIs into GraphQL automatically.

💡 Hint

Think about how large GraphQL schemas are managed in parts.

A subgraph is a modular piece of the overall GraphQL schema and data, enabling teams to develop and deploy parts of the graph independently. It is not a cache, database table, or conversion tool.

Practice

1. What is the main purpose of defining a subgraph in a GraphQL architecture?

easy

A. To split a large graph into smaller, manageable parts

B. To increase the number of queries sent to the server

C. To combine multiple databases into one

D. To replace the need for a schema in GraphQL

Solution

1. Step 1: Understand the concept of subgraphs

   Subgraphs are used to divide a big graph into smaller parts for clarity and manageability.

2. Step 2: Identify the main purpose

   The main goal is to make data easier to manage and improve collaboration by splitting the graph.

3. Final Answer:

   To split a large graph into smaller, manageable parts -> Option A

4. Quick Check:

   Subgraphs = smaller parts [OK]

Hint: Subgraphs break big graphs into smaller pieces [OK]

Common Mistakes:

• Thinking subgraphs increase query count
• Confusing subgraphs with database merging
• Believing subgraphs replace schemas

2. Which of the following is the correct way to define a unique key for a subgraph entity using the @key directive?

easy

A. type Product @key(fields: id) { id: ID! name: String }

B. type Product @key(id) { id: ID! name: String }

C. type Product @key(fields: "id") { id: ID! name: String }

D. type Product @key("id") { id: ID! name: String }

Solution

1. Step 1: Recall the syntax of the @key directive

   The @key directive requires the fields argument as a string specifying the unique key fields.

2. Step 2: Match the correct syntax

   type Product @key(fields: "id") { id: ID! name: String } correctly uses @key(fields: "id") with quotes around the field name.

3. Final Answer:

   type Product @key(fields: "id") { id: ID! name: String } -> Option C

4. Quick Check:

   @key(fields: "id") = correct syntax [OK]

Hint: Use quotes around fields in @key directive [OK]

Common Mistakes:

• Omitting quotes around field names
• Using @key without 'fields:' keyword
• Passing field name without string quotes

3. Given this subgraph definition:

type User @key(fields: "userID") {
  userID: ID!
  name: String
  email: String
}

What will happen if you query for { user { userID name } } in a federated setup?

medium

A. The query returns userID and name for the User entity correctly

B. The query fails because email is missing in the query

C. The query returns only userID but not name

D. The query returns an error due to missing @key directive

Solution

1. Step 1: Understand the @key directive role

   The @key directive marks userID as the unique identifier for User entities in the subgraph.

2. Step 2: Analyze the query fields

   The query requests userID and name, both defined in the User type, so it will succeed.

3. Final Answer:

   The query returns userID and name for the User entity correctly -> Option A

4. Quick Check:

   Query fields in schema = successful fetch [OK]

Hint: Query only requested fields defined in subgraph [OK]

Common Mistakes:

• Assuming all fields must be queried
• Confusing @key with required query fields
• Expecting error if some fields are omitted

4. Consider this subgraph schema:

type Product @key(fields: "sku") {
  sku: ID!
  name: String
  price: Float
}

Which of the following fixes the error in this subgraph definition?

Option A:

type Product @key(fields: "id") {
  sku: ID!
  name: String
  price: Float
}

Option B:

type Product @key(fields: sku) {
  sku: ID!
  name: String
  price: Float
}

Option C:

type Product @key(fields: "sku") {
  sku: ID!
  name: String
  price: Float
}

Option D:

type Product {
  sku: ID!
  name: String
  price: Float
}

medium

A. Change @key fields to "id" instead of "sku"

B. No change needed; the original schema is correct

C. Remove quotes around sku in @key directive

D. Remove the @key directive entirely

Solution

1. Step 1: Check the original @key syntax

   The original schema uses @key(fields: "sku") correctly with quotes around the field name.

2. Step 2: Verify field existence

   The field sku exists and matches the @key directive, so no error is present.

3. Final Answer:

   No change needed; the original schema is correct -> Option B

4. Quick Check:

   Correct @key syntax and matching field = no error [OK]

Hint: Quotes around fields in @key are required [OK]

Common Mistakes:

• Removing quotes around fields in @key
• Using a field name not present in the type
• Removing @key directive causing federation errors

5. You want to create a subgraph for an Orders service. Each Order has a unique orderID and a list of items. Which is the best way to define the subgraph schema to support federation and ensure uniqueness?

hard

A. type Order @key(fields: "orderID items") { orderID: ID! items: [String] }

B. type Order { orderID: ID! items: [String] }

C. type Order @key(fields: "items") { orderID: ID! items: [String] }

D. type Order @key(fields: "orderID") { orderID: ID! items: [String] }

Solution

1. Step 1: Identify the unique key for the Order entity

   The unique identifier is orderID, so it should be used in the @key directive.

2. Step 2: Check the correct @key usage

   Using @key(fields: "orderID") correctly marks orderID as the unique key for federation.

3. Final Answer:

   type Order @key(fields: "orderID") { orderID: ID! items: [String] } -> Option D

4. Quick Check:

   Unique key = orderID in @key [OK]

Hint: Use unique ID field in @key directive for subgraph entities [OK]

Common Mistakes:

• Omitting @key directive causing federation issues
• Using non-unique fields like items in @key
• Combining multiple fields incorrectly in @key