Schema evolution strategies in GraphQL - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is schema evolution in GraphQL?

Schema evolution is the process of changing a GraphQL schema over time without breaking existing clients. It allows adding, modifying, or deprecating fields safely.

beginner

Why should you deprecate fields instead of removing them immediately?

Deprecating fields gives clients time to update their queries before the field is removed, preventing sudden breaks in applications.

beginner

What is a common strategy to add new features in a GraphQL schema without breaking clients?

Add new fields or types without changing or removing existing ones. This keeps old queries working while enabling new functionality.

intermediate

How can you handle breaking changes in a GraphQL schema safely?

Use versioning or deprecate old fields first, communicate changes clearly, and provide clients time to migrate before removing fields.

beginner

What role does documentation play in schema evolution?

Good documentation helps clients understand changes, deprecated fields, and new features, making evolution smoother and less error-prone.

What is the recommended way to remove a field from a GraphQL schema?

A Remove it immediately without notice

B Rename it without warning

C Deprecate it first, then remove later

D Change its type directly

Deprecating a field first allows clients to adapt before the field is removed, preventing breaking changes.

Which of these is a safe way to add new functionality to a GraphQL schema?

A Change existing field types

B Remove old fields

C Rename existing fields

D Add new fields or types

Adding new fields or types does not break existing clients and is the safest way to evolve a schema.

What does deprecating a field in GraphQL do?

A Marks the field as discouraged but still available

B Immediately deletes the field

C Changes the field's data type

D Hides the field from all clients

Deprecation marks a field as discouraged to use but keeps it available for backward compatibility.

Why is versioning sometimes used in schema evolution?

A To force clients to update immediately

B To support multiple schema versions simultaneously

C To remove deprecated fields faster

D To rename all fields

Versioning allows running multiple schema versions so clients can migrate at their own pace.

Which practice helps clients understand schema changes best?

A Providing clear documentation and changelogs

B Removing fields without notice

C Ignoring documentation

D Changing field names randomly

Clear documentation and changelogs help clients adapt to schema changes smoothly.

Explain how you would safely remove a field from a GraphQL schema without breaking existing clients.

Think about gradual change and client updates.

Describe strategies to add new features to a GraphQL schema while keeping old clients working.

Focus on non-breaking additions.

Practice

1. What is the main purpose of schema evolution in GraphQL APIs?

easy

A. To update the API without breaking existing client applications

B. To remove all old fields immediately from the schema

C. To prevent any changes to the API once deployed

D. To make all fields mandatory for clients

Solution

1. Step 1: Understand schema evolution concept

   Schema evolution allows changes to the API while keeping existing clients working.

2. Step 2: Identify the correct purpose

   Removing fields immediately or making all fields mandatory breaks clients, so those are incorrect.

3. Final Answer:

   To update the API without breaking existing client applications -> Option A

4. Quick Check:

   Schema evolution = safe API updates [OK]

Hint: Schema evolution means safe API changes without breaking clients [OK]

Common Mistakes:

• Thinking schema evolution means removing fields immediately
• Believing all fields must be mandatory
• Assuming no changes are allowed after deployment

2. Which of the following is the correct way to mark a field as deprecated in a GraphQL schema?

easy

A. type User { name: String @remove(reason: "Use fullName instead") }

B. type User { name: String deprecated: true }

C. type User { name: String @deprecated(reason: "Use fullName instead") }

D. type User { name: String deprecated(reason: "Use fullName instead") }

Solution

1. Step 1: Recall GraphQL deprecation syntax

   GraphQL uses the @deprecated directive with a reason argument to mark fields deprecated.

2. Step 2: Check each option's syntax

   type User { name: String @deprecated(reason: "Use fullName instead") } uses correct @deprecated directive syntax; others are invalid or incorrect.

3. Final Answer:

   type User { name: String @deprecated(reason: "Use fullName instead") } -> Option C

4. Quick Check:

   @deprecated directive syntax = type User { name: String @deprecated(reason: "Use fullName instead") } [OK]

Hint: Use @deprecated(reason: "...") to mark fields deprecated [OK]

Common Mistakes:

• Using deprecated: true instead of @deprecated directive
• Using @remove directive which does not exist
• Omitting the @ symbol before deprecated

3. Given this GraphQL schema snippet:

type Query {
  user(id: ID!): User
}

type User {
  id: ID!
  name: String
  email: String @deprecated(reason: "Use contactEmail instead")
  contactEmail: String
}

What happens if a client queries for email field?

medium

A. The query succeeds but clients get a deprecation warning for email

B. The query fails because email is removed

C. The query returns null for email always

D. The query returns contactEmail value instead of email

Solution

1. Step 1: Understand @deprecated behavior in GraphQL

   Deprecated fields still exist and return data but signal clients to avoid using them.

2. Step 2: Analyze the query effect

   Querying email returns its value but clients should see a deprecation warning.

3. Final Answer:

   The query succeeds but clients get a deprecation warning for email -> Option A

4. Quick Check:

   Deprecated fields return data with warnings [OK]

Hint: Deprecated fields still return data but warn clients [OK]

Common Mistakes:

• Assuming deprecated fields are removed immediately
• Thinking deprecated fields return null
• Believing deprecated fields auto-redirect to new fields

4. Consider this schema update attempt:

type User {
  id: ID!
  name: String
  email: String
}

# Update:
type User {
  id: ID!
  name: String
  contactEmail: String
}

What is the main problem with this update?

medium

A. GraphQL does not allow adding new fields to existing types

B. Adding contactEmail without deprecating email causes syntax error

C. You must rename email to contactEmail in one step

D. Removing email field breaks existing clients still using it

Solution

1. Step 1: Identify schema evolution best practice

   Removing fields immediately breaks clients that still query those fields.

2. Step 2: Analyze the update

   The update removes email without deprecation, causing breaking changes.

3. Final Answer:

   Removing email field breaks existing clients still using it -> Option D

4. Quick Check:

   Immediate removal breaks clients [OK]

Hint: Never remove fields immediately; deprecate first [OK]

Common Mistakes:

• Thinking adding fields causes syntax errors
• Believing renaming must be one-step without deprecation
• Assuming GraphQL forbids adding new fields

5. You want to evolve a GraphQL schema by replacing a field phone with mobilePhone without breaking clients. Which strategy is best?

hard

A. Remove phone immediately and add mobilePhone

B. Add mobilePhone as optional, deprecate phone with reason, keep both for now

C. Rename phone to mobilePhone directly without deprecation

D. Keep only phone and do not add mobilePhone

Solution

1. Step 1: Apply schema evolution best practice

   Adding new fields as optional and deprecating old ones avoids breaking clients.

2. Step 2: Evaluate options

   Add mobilePhone as optional, deprecate phone with reason, keep both for now follows best practice; others cause breaking changes or no evolution.

3. Final Answer:

   Add mobilePhone as optional, deprecate phone with reason, keep both for now -> Option B

4. Quick Check:

   Deprecate old, add new optional field [OK]

Hint: Add new optional field, deprecate old with reason [OK]

Common Mistakes:

• Removing old field immediately
• Renaming fields without deprecation
• Not adding new field at all