AI and GraphQL schema review

End-of-lesson check

15 questions · take it digitally for instant feedback at tendril.neural-forge.io/learn/quiz/end-ai-coding-llm-graphql-schema-review-creators

1. Which task is an LLM well-equipped to perform when reviewing a GraphQL schema change?

   1. Coordinate deprecation timelines with client development teams
   2. Manage communication between multiple downstream API consumers
   3. Classify schema changes as breaking, additive, or risky
   4. Decide when a deprecated field should be completely removed

2. In the context of GraphQL schema reviews, what is a 'footgun'?

   1. A field that throws an error when queried
   2. A schema design pattern that frequently leads to runtime bugs or confusion
   3. A security vulnerability in the schema
   4. A deprecated API endpoint

3. What limitation do LLMs have when reviewing federated GraphQL schemas?

   1. They cannot read SDL syntax
   2. They may miss subgraph-specific constraints unique to federated architectures
   3. They always miss deprecation suggestions
   4. They cannot detect breaking changes

4. When prompting an LLM to review a GraphQL schema PR, what specific output should you request?

   1. The complete rewritten schema in TypeScript
   2. A list of all query performance metrics
   3. Tag each change as breaking/additive/risky and cite consumer impact
   4. A summary of how many lines were changed

5. Which of the following is an example of a breaking change in a GraphQL schema?

   1. Adding a new query root entry point
   2. Removing a field that existing queries depend on
   3. Adding documentation to an existing field
   4. Adding a new optional field to a type

6. What can an LLM suggest when it detects a field that should be deprecated?

   1. Reject the entire PR
   2. Ignore it and continue the review
   3. Add deprecation comments and suggest alternative fields
   4. Delete the field immediately without notification

7. Which type of schema change would typically be classified as 'additive' rather than 'breaking'?

   1. Changing a field's type from String to Int
   2. Removing an input field
   3. Renaming a field
   4. Adding a new enum value

8. What does SDL stand for in the context of GraphQL?

   1. Synchronous Data Link
   2. System Development Lifecycle
   3. Schema Definition Language
   4. Structured Data Language

9. A nullable ID field is considered a footgun because:

   1. It causes syntax errors in the schema
   2. It prevents queries from executing
   3. It forces clients to handle null cases everywhere and can cause runtime errors
   4. It automatically deletes data

10. What consumer impact should be cited when a field is changed from non-nullable to nullable?

    1. Clients may receive null and need null-checks, potentially causing runtime errors
    2. Clients will automatically use the new default value
    3. The API will run faster
    4. No impact—clients will work exactly as before

11. Which statement about LLMs and deprecation timelines is correct?

    1. LLMs cannot decide deprecation timelines—they lack context about business needs
    2. LLMs always recommend immediate removal of deprecated fields
    3. LLMs ignore deprecation when reviewing schemas
    4. LLMs can determine optimal deprecation windows based on user analytics

12. When reviewing a federated schema, what might an LLM miss that a human familiar with federation would catch?

    1. Subgraph-specific @key directive violations
    2. Type syntax errors
    3. Missing documentation
    4. Typos in field names

13. What distinguishes a 'risky' change from a 'breaking' change in schema review?

    1. There is no difference—these terms are interchangeable
    2. Risky changes only affect read operations
    3. Breaking changes cause immediate failures; risky changes work now but may cause issues
    4. Risky changes only affect mutations, not queries

14. To get useful schema review from an LLM, what should you provide in your prompt?

    1. Only the new schema version
    2. The compiled JavaScript output
    3. Both the old and new SDL versions
    4. A summary of the changes in plain English

15. Which scenario represents the strongest use case for AI-assisted schema review?

    1. Deciding whether to notify third-party API consumers of changes
    2. Writing marketing copy for a new API feature
    3. Detecting that a field type change from String! to String is risky
    4. Scheduling the next schema release