Nach der einfachen String-Query aus Kapitel 5 geht es jetzt um komplexe Typen - eigene Objekttypen mit mehreren Feldern - und um Input-Typen, die strukturierte Argumente statt einzelner Skalare entgegennehmen.

Die eingebauten Skalartypen

GraphQL bringt fünf eingebaute Skalartypen mit, auf die jedes Schema aufbaut: Int, Float, String, Boolean und ID (ein String, der als eindeutiger Bezeichner semantisch markiert ist). Magento selbst definiert keine zusätzlichen Custom-Scalars für Dinge wie Datumswerte - Zeitstempel werden als formatierte String-Werte übertragen, nicht als eigener DateTime-Skalar. Diese Konvention übernimmt auch das Veranstaltungen-Projekt ab Block 4.

Einen eigenen Objekttyp deklarieren

Ein Beispiel im Warm-up-Modul: eine Query shopContact, die statt eines einzelnen Strings ein strukturiertes Objekt mit mehreren Feldern liefert.

type Query {
    shopContact: ShopContact
        @resolver(class: "Mironsoft\\GraphqlDemo\\Model\\Resolver\\ShopContact")
        @doc(description: "Returns the shop's public contact details")
}

type ShopContact @doc(description: "Public contact details of the shop") {
    company_name: String
    email: String
    phone: String
    support_hours: [String]
}

type ShopContact { ... } ist ein eigener, benannter GraphQL-Typ - kein PHP-Interface, sondern reine Schema-Deklaration. [String] deklariert eine Liste von Strings (Kapitel 7 vertieft Listen-Semantik im Detail).

<?php

declare(strict_types=1);

namespace Mironsoft\GraphqlDemo\Model\Resolver;

use Magento\Framework\GraphQl\Config\Element\Field;
use Magento\Framework\GraphQl\Query\ResolverInterface;
use Magento\Framework\GraphQl\Schema\Type\ResolveInfo;

/**
 * Resolves the shopContact query field.
 */
class ShopContact implements ResolverInterface
{
    /**
     * Returns the shop's static contact details as an array matching the
     * ShopContact GraphQL type.
     *
     * @param Field $field Resolved GraphQL field configuration
     * @param mixed $context Resolver context
     * @param ResolveInfo $info GraphQL resolve tree info
     * @param array|null $value Parent resolver's value, unused here
     * @param array|null $args Arguments passed to the shopContact field
     * @return array<string, mixed>
     */
    public function resolve(
        Field $field,
        $context,
        ResolveInfo $info,
        ?array $value = null,
        ?array $args = null
    ): array {
        return [
            'company_name' => 'Mironsoft',
            'email' => 'kontakt@mironsoft.de',
            'phone' => '+49 30 1234567',
            'support_hours' => ['Mo-Fr 9-17 Uhr'],
        ];
    }
}

Entscheidend: Der Resolver liefert ein assoziatives Array, dessen Schlüssel exakt den Feldnamen aus type ShopContact entsprechen. Für jedes einzelne Feld (company_name, email, ...) greift danach automatisch der in Kapitel 2 erwähnte Default-Resolver - eigene Resolver-Klassen pro Feld sind nur nötig, wenn ein Feld eigene Logik braucht.

Eigene Input-Typen für strukturierte Argumente

Genau wie Objekttypen für Rückgabewerte gibt es Input-Typen für Argumente - deklariert mit input statt type. Sie dürfen ausschließlich aus Skalaren, Enums und weiteren Input-Typen bestehen, niemals aus regulären Objekttypen.

input ShopContactFilterInput {
    department: String
    language: String
}

type Query {
    shopContact(filter: ShopContactFilterInput): ShopContact
        @resolver(class: "Mironsoft\\GraphqlDemo\\Model\\Resolver\\ShopContact")
}

Im Resolver landet ein solcher Input-Typ als verschachteltes Array in $args['filter'] - $args['filter']['language'] ?? null liest dann den einzelnen Wert. Dieses Muster - ein Input-Typ als einziges strukturiertes Argument statt vieler loser Skalar-Argumente - ist in Magentos eigenen Mutations Standard (Kapitel 16) und wird im Veranstaltungen-Projekt ab Kapitel 14 für Filter und Sortierung übernommen.

Kapitel 7 vertieft, wie Pflichtfelder (!), Nullable-Felder und Listen im Schema korrekt modelliert werden - ein Thema, das bei ShopContact hier bewusst noch vereinfacht war.