GraphQL-Typen sind standardmäßig nullable - jedes Feld darf null zurückgeben, sofern nicht explizit anders deklariert. Dieses Kapitel zeigt, wie !, Listen-Klammern [...] und ihre Kombinationen das Verhalten steuern - ein Thema, das beim Veranstaltungen-Schema in Kapitel 12 direkt zur Anwendung kommt.

Das Ausrufezeichen: Non-Null

String heißt "dieses Feld darf null sein", String! heißt "dieses Feld ist garantiert nicht null". Gibt ein Resolver für ein als ! deklariertes Feld dennoch null zurück, antwortet Magento nicht mit null im Feld, sondern mit einem GraphQL-Fehler - die Non-Null-Garantie wird zur Laufzeit durchgesetzt, nicht nur dokumentiert.

type Example {
    id: ID!            # garantiert vorhanden
    title: String!     # garantiert vorhanden
    subtitle: String   # darf fehlen (null)
}

Non-Null bei Argumenten: Pflicht-Parameter

Dasselbe ! gilt auch für Argumente - dort bedeutet es, dass der Client diesen Wert zwingend mitschicken muss, sonst schlägt schon die Validierung der Anfrage fehl, bevor überhaupt ein Resolver aufgerufen wird:

type Query {
    productBySku(sku: String!): Product   # sku ist zwingend
}

Listen und ihre vier Kombinationen

Eckige Klammern [...] markieren eine Liste. In Kombination mit ! ergeben sich vier unterschiedliche Bedeutungen, die häufig verwechselt werden:

• [String] - die Liste selbst darf null sein, und einzelne Einträge in der Liste dürfen ebenfalls null sein.
• [String]! - die Liste selbst ist garantiert vorhanden (mindestens ein leeres Array), aber einzelne Einträge dürfen null sein.
• [String!] - die Liste selbst darf null sein, aber wenn sie vorhanden ist, ist kein Eintrag null.
• [String!]! - sowohl die Liste als auch jeder einzelne Eintrag sind garantiert nicht null - die strengste Variante.

// Resolver für ein Feld vom Typ [String!]!
// -> Rückgabe MUSS ein Array sein, und kein Element darf null sein:
return ['Montag', 'Dienstag', 'Mittwoch'];

// Für [String] wäre auch das hier gültig:
return null;
return ['Montag', null, 'Mittwoch'];

Wann sich Non-Null wirklich lohnt

Non-Null wirkt auf den ersten Blick harmlos strenger und damit "sicherer" - in der Praxis ist das Gegenteil oft der Fall. Ein als ! deklariertes Feld, das der Resolver in einem Randfall doch nicht befüllen kann, reißt beim Rendern verschachtelter Queries den kompletten übergeordneten Ast der Antwort mit in den Fehler (GraphQL nennt das "Null-Bubbling"). Ein Feld, das plausibel auch einmal fehlen kann (z. B. eine optionale Kurzbeschreibung), sollte deshalb nullable bleiben.

Faustregel für das kommende Veranstaltungen-Schema

Block 4 hält sich an eine einfache Leitlinie: Spalten mit nullable="false" in db_schema.xml werden im GraphQL-Schema als ! deklariert (z. B. title: String!, identifier: String!), optionale Spalten (nullable="true", z. B. capacity) bleiben nullable. Diese 1:1-Abbildung zwischen DB-Schema und GraphQL-Schema ist kein Zwang der Spezifikation, aber eine verlässliche Faustregel, die Überraschungen vermeidet.

Mit Non-Null, Listen und ihrer Kombinatorik im Kopf ist Block 2 abgeschlossen. Block 3 zeigt, wie sich bestehende Core-Typen sauber erweitern lassen, ohne sie zu duplizieren.