GraphQL-Schema-Review

Prüft ein GraphQL-Schema auf N+1-Fallen, Nullability-Disziplin, Evolution-Schmerz und Business-Abbildung.

Zuletzt geprüft 23. April 2026

Prompt

Review the following GraphQL schema. Focus on structural issues, not taste.

Check and report findings grouped:

1. NULLABILITY
   - Fields marked nullable that should be required (and vice versa)
   - Lists: `[Type]` vs `[Type!]` vs `[Type!]!` - which is correct here?

2. N+1 / PERF RISK
   - Fields likely to trigger per-row fetches
   - Collections without pagination
   - Missing DataLoader-opportunity hints

3. SCHEMA EVOLUTION
   - Enums that should be OpenEnums (extensible?)
   - Union/Interface usage - appropriate?
   - Breaking-change risks (renamed fields, required args added)

4. BUSINESS MODELING
   - Does the schema express the domain, or is it a DB dump?
   - Fields that leak implementation details
   - Mutations: input types present? Payloads for errors?

5. AUTH / SCOPE
   - Fields that should be role-gated
   - Mutations returning too much (leaky payloads)

For each finding:
- Where (type.field)
- Why it matters
- Concrete fix

Rules:
- No bikeshedding naming unless inconsistent
- Connection pattern (Relay) only if project uses it - don't force it

Schema:
[PASTE SDL]

Wann nutzen

Für Schema-PRs, bei denen Struktur viel teurer zu fixen ist als Code. Nullability-Fehler und N+1-Risiken früh abfangen.

Use-Cases

  • Neuer Schema-Teil für ein großes Feature.
  • Migration einer REST-API nach GraphQL.
  • Consumer-Feedback: 'es ist alles null' - Disziplin-Check.

Getestet mit

Das Business-Modeling-Feedback lohnt sich am meisten: Schemas, die 1:1 die DB spiegeln, werden schnell zu Dauer-Wartungsfällen.