Bevor eigene Queries geschrieben werden, hilft ein praktischer Blick auf das, was bereits funktioniert: der bestehende /graphql-Endpunkt gegen den eigenen Entwicklungs-Shop. Das schärft das Gefühl für Request-/Response-Format, bevor Kapitel 4 das erste eigene Modul anlegt.

Den Endpunkt finden

Der GraphQL-Endpunkt liegt unter der Basis-URL des Shops, Pfad /graphql - bei diesem Projekt lokal also z. B. https://mironsoft.test/graphql. Es gibt keinen separaten Port und keine separate Domain, der Endpunkt läuft über denselben Docker-Container wie der reguläre Storefront.

Werkzeuge für erste Abfragen

Drei Wege eignen sich zum Ausprobieren, ganz ohne eigenen Code:

• curl - immer verfügbar, gut für schnelle Checks und für spätere CI-Skripte.
• Ein dedizierter GraphQL-Client wie Altair, Insomnia oder der GraphQL-Modus von Postman - komfortabler dank Syntax-Highlighting, Schema-Introspection und Autovervollständigung.
• Automatisierte Tests gegen GraphQlAbstract - dazu ausführlich Kapitel 24, hier zunächst nur manuell.

curl -s https://mironsoft.test/graphql \
  -H "Content-Type: application/json" \
  -d '{"query": "{ storeConfig { store_code base_currency_code } }"}' | jq

Der Request-Body ist reines JSON mit einem Feld query (String) und optional variables (Objekt) sowie operationName - dazu gleich mehr. Die Antwort ist ebenfalls JSON, mit einem Feld data für erfolgreiche Felder und optional errors für fehlgeschlagene.

Schema-Introspection: das Schema selbst abfragen

GraphQL-Schemas sind selbstbeschreibend - das Schema lässt sich per Introspection-Query erkunden, genau das nutzen GraphQL-Clients für Autovervollständigung:

query {
  __type(name: "ProductInterface") {
    name
    fields {
      name
      type { name kind }
    }
  }
}

In einem GraphQL-Client wie Altair reicht ein Klick auf "Docs", um das komplette zusammengeführte Schema (Kapitel 2) durchsuchbar zu machen - inklusive aller Core-Typen wie ProductInterface, CustomerOutput oder CartItemInterface.

Variablen statt String-Verkettung

Werte gehören nicht direkt in den Query-String, sondern in ein separates variables-Objekt - das verhindert Injection-ähnliche Fehler und macht Queries wiederverwendbar:

{
  "query": "query GetProduct($sku: String!) { products(filter: { sku: { eq: $sku } }) { items { name price_range { minimum_price { final_price { value } } } } } }",
  "variables": { "sku": "24-MB01" }
}

Fehlerantworten richtig lesen

Ein GraphQL-Response kann data und errors gleichzeitig enthalten - Teilfehler auf einzelnen Feldern schließen erfolgreiche Nachbarfelder nicht aus. Jeder Fehler trägt eine category in extensions, die verrät, um welche Art Fehler es sich handelt - mehr dazu in Kapitel 19 und Kapitel 25.

{
  "errors": [
    {
      "message": "Field \"typo_field\" doesn't exist on type \"Query\"",
      "extensions": { "category": "graphql" }
    }
  ]
}

Mit dem Gefühl für Request-Format, Introspection und Fehlerformat geht es in Block 2 an die erste eigene Query in einem eigenen Modul.