Subgraph definition in GraphQL - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is a subgraph in GraphQL?

A subgraph is a smaller part of a larger GraphQL graph. It defines a set of types and fields that focus on a specific domain or service.

beginner

What does a subgraph definition usually include?

It includes the schema with types, queries, mutations, and sometimes directives that describe the data and operations for that subgraph.

intermediate

Why do we use subgraphs in a GraphQL architecture?

Subgraphs help split a big graph into smaller, manageable parts. This makes development easier and allows teams to work independently on different domains.

intermediate

How does a subgraph relate to a federated GraphQL gateway?

A federated gateway combines multiple subgraphs into one unified graph. Each subgraph provides part of the overall schema that the gateway merges.

advanced

What is the role of the @key directive in a subgraph definition?

The @key directive marks a field or set of fields as a unique identifier for an entity. It helps the gateway know how to reference and join data across subgraphs.

What does a subgraph in GraphQL represent?

A A database table

B A frontend UI component

C A part of the overall graph focusing on a specific domain

D A GraphQL query operation

A subgraph is a focused part of the overall graph, representing a domain or service.

Which directive is commonly used in subgraph definitions to identify entities uniquely?

A @key

B @entity

C @unique

D @id

The @key directive marks fields as unique identifiers for entities in subgraphs.

What is the main purpose of splitting a GraphQL schema into subgraphs?

A To allow multiple teams to work independently on different parts

B To reduce the number of queries sent

C To improve query speed by caching

D To avoid using GraphQL federation

Splitting into subgraphs helps teams work independently and manage complexity.

In a federated GraphQL setup, what combines the subgraphs into one schema?

A GraphQL client

B Federated gateway

C Database engine

D GraphQL server

The federated gateway merges subgraphs into a single unified schema.

Which of the following is NOT typically part of a subgraph definition?

A Directives

B Resolvers

C Type definitions

D UI components

UI components are not part of a subgraph definition; subgraphs define schema and resolvers.

Explain what a subgraph definition is and why it is useful in GraphQL.

Think about how big projects can be divided into smaller pieces.

Describe the role of the @key directive in a subgraph definition and how it helps federation.

Focus on how different subgraphs connect their data.

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