Schema evolution strategies in GraphQL - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Why use schema evolution in GraphQL?

Imagine you have a GraphQL API used by many apps. You want to add new features without breaking old apps. Why is schema evolution important here?

A It allows adding new fields without removing or changing existing ones, so old apps keep working.

B It deletes old fields automatically to keep the schema small.

C It forces all clients to update immediately when the schema changes.

D It disables queries that use deprecated fields.

💡 Hint

Think about how to keep old apps working while adding new features.

Schema evolution lets you add new fields or types without breaking existing clients. This way, old apps continue to work while new apps can use new features.

❓ query_result

intermediate

What is the result of querying a deprecated field?

Given this GraphQL schema snippet:

type User { id: ID! name: String! age: Int @deprecated(reason: "Use birthYear instead") birthYear: Int }

What happens if a client queries the age field?

GraphQL

query { user(id: "1") { id name age } }

A The query returns birthYear instead of age automatically.

B The query fails with an error because age is deprecated.

C The query returns null for age without any warning.

D The query returns the age value but shows a deprecation warning in the schema documentation.

💡 Hint

Deprecated fields still work but are marked as discouraged.

Deprecated fields remain accessible to avoid breaking clients. They show warnings in documentation but do not cause errors.

📝 Syntax

advanced

Which schema change is NOT backward compatible?

Which of these GraphQL schema changes will break existing clients?

A Adding a new optional field to a type.

B Changing a field's type from String to Int.

C Adding a new enum value.

D Marking a field as deprecated.

💡 Hint

Think about what happens if a client expects a string but gets an integer.

Changing a field's type breaks clients expecting the old type. Adding optional fields or enum values and deprecating fields are backward compatible.

❓ optimization

advanced

How to safely remove a deprecated field?

You want to remove a deprecated field from your GraphQL schema without breaking clients. What is the best approach?

A Keep the field deprecated for a while, notify clients, then remove it in a future version.

B Replace the field with a different type without warning.

C Remove the field immediately and update all clients at once.

D Rename the field to a new name without deprecating it first.

💡 Hint

Think about giving clients time to adapt.

Deprecate fields first to warn clients, then remove them after enough time has passed to avoid breaking existing clients.

🧠 Conceptual

expert

What is a non-breaking schema evolution strategy for changing a field's type?

You need to change a field's type in a GraphQL schema, but you want to avoid breaking existing clients. Which strategy achieves this?

A Remove the old field and add a new field with the same name but different type.

B Change the field's type directly and update all clients immediately.

C Create a new field with the new type and keep the old field deprecated until removal.

D Use a union type to combine old and new types in the same field.

💡 Hint

Think about how to keep old clients working while introducing new types.

Adding a new field with the new type and deprecating the old one allows clients to migrate gradually without breaking.