Subgraph definition in GraphQL - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to define a subgraph with a name.

GraphQL

subgraph [1] {
  // schema details here
}

Drag options to blanks, or click blank then click option'

Aschema

Bquery

Ctype

DMySubgraph

Attempts:

3 left

💡 Hint

Common Mistakes

Using reserved keywords like 'schema' or 'type' as the subgraph name.

Leaving the subgraph name blank.

The subgraph name is required after the subgraph keyword to identify it uniquely.

2fill in blank

medium

Complete the code to specify the GraphQL schema inside the subgraph.

GraphQL

subgraph MySubgraph {
  [1] {
    query: Query
  }
}

Drag options to blanks, or click blank then click option'

Aschema

Btype

Cinterface

Dfragment

Attempts:

3 left

💡 Hint

Common Mistakes

Using type instead of schema for the schema block.

Omitting the schema block.

The schema block defines the entry points like query for the subgraph.

3fill in blank

hard

Fix the error in the subgraph definition by completing the type declaration.

GraphQL

type Query [1]
  product(id: ID!): Product
}

Drag options to blanks, or click blank then click option'

Aimplements Node

B{

Cextends

Dinterface

Attempts:

3 left

💡 Hint

Common Mistakes

Using implements Node without defining the interface.

Missing the opening curly brace.

The type declaration must open with a curly brace { to define fields.

4fill in blank

hard

Complete the code to define a Product type with an ID and a name field.

GraphQL

type Product { 
  id: [1]!
  name: String
}

Drag options to blanks, or click blank then click option'

A{

BID

CInt

DString

Attempts:

3 left

💡 Hint

Common Mistakes

Using Int or String for the id field instead of ID.

Omitting the opening curly brace.

The type fields must be inside curly braces { and the ID field uses the ID scalar type.

5fill in blank

hard

Fill both blanks to define a subgraph with a schema and a Product type with id and name.

GraphQL

subgraph [1] {
  [2] {
    query: Query
  }

  type Product { 
    id: ID!
    name: String
  }
}

Drag options to blanks, or click blank then click option'

AMySubgraph

Bschema

C{

Dtype

Attempts:

3 left

💡 Hint

Common Mistakes

Using type instead of schema for the schema block.

Missing curly braces for the type fields.

The subgraph name is MySubgraph, the schema block is schema, and the type fields start with {.

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