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.