26 Kapitel, ein durchgehendes Projekt, eine vollständige Veranstaltungen-GraphQL-API von der ersten Schema-Deklaration bis zu ACL und Batch-Resolvern. Dieses letzte Kapitel bündelt die wichtigsten Muster als Nachschlagewerk für die eigene Praxis - ohne neue Inhalte, nur Verdichtung.

Schema-Grundgerüst

type Query {
    myField(arg: String): MyType
        @resolver(class: "Vendor\\Module\\Model\\Resolver\\MyField")
        @doc(description: "...")
}

type Mutation {
    myMutation(input: MyMutationInput!): MyMutationOutput
        @resolver(class: "Vendor\\Module\\Model\\Resolver\\MyMutation")
}

extend type ExistingCoreType {
    my_extra_field: String @resolver(class: "...")
}

Resolver-Skelett

final class MyField implements ResolverInterface
{
    public function __construct(
        private readonly MyDataProvider $dataProvider,
    ) {
    }

    public function resolve(
        Field $field,
        $context,
        ResolveInfo $info,
        ?array $value = null,
        ?array $args = null
    ): array {
        return $this->dataProvider->getData($args);
    }
}

Die vier GraphQL-Exceptions

• GraphQlInputException - fachlich ungültige Eingabe.
• GraphQlAuthorizationException - fehlende Berechtigung.
• GraphQlNoSuchEntityException - Entität existiert nicht.
• GraphQlAlreadyExistsException - eindeutiger Wert bereits vergeben.
• Immer mit __('...') statt rohem String (übersetzbar).

Authentifizierungs-Check im Resolver

if ($context->getUserType() !== UserContextInterface::USER_TYPE_CUSTOMER
    || !$context->getExtensionAttributes()->getIsCustomer()
) {
    throw new GraphQlAuthorizationException(__('...'));
}

$customerId = (int) $context->getUserId();

Batch-Resolver gegen N+1

final class MyBatchField implements BatchResolverInterface
{
    public function resolve(array $requests): BatchResponse
    {
        $response = new BatchResponse();
        // alle IDs aus $requests sammeln, EINE Abfrage, Ergebnisse zuordnen
        foreach ($requests as $request) {
            $response->addResponse($request, /* ... */ null);
        }

        return $response;
    }
}

Die zehn goldenen Regeln dieser Serie

1. Nach jeder schema.graphqls-Änderung sofort bin/cache-clean config - kein setup:di:compile nötig, aber immer ein Cache-Clean.
2. Resolver bleiben dünn, DataProvider tragen die eigentliche Logik - aber nur, wenn die Logik das rechtfertigt (Kapitel 15).
3. Bestehende Core-Typen mit extend type erweitern statt neue, isolierte Typen zu duplizieren.
4. Bestehende Core-Input-Typen (FilterTypeInput, SortEnum) wiederverwenden statt eigene neu zu erfinden.
5. Non-Null (!) nur für Felder, die fachlich wirklich nie fehlen können - Null-Bubbling reißt sonst ganze Antwortzweige mit.
6. DataProvider nutzen Repositories, nicht nackte Collections - addFieldToFilter() immer in Array-Form ['eq' => $value].
7. Für Fehlerfälle immer eine der vier GraphQL-Exceptions werfen, nie eine generische Exception, die im Produktivmodus maskiert wird.
8. getExtensionAttributes()->getIsCustomer() statt einer reinen getUserId() > 0-Prüfung für echte Kundenerkennung.
9. Bei absehbar großen Listen mit eigenen Feld-Resolvern von Anfang an BatchResolverInterface statt ResolverInterface in Betracht ziehen.
10. Bei jedem Problem zuerst Cache-Clean, dann Introspection, dann Developer-Mode und exception.log prüfen - erst danach den eigenen Code verdächtigen.

Damit endet diese Serie. Von der ersten Frage "Was ist GraphQL überhaupt?" bis zu einer vollständigen, performanten, getesteten und abgesicherten Veranstaltungen-API - die hier gezeigten Muster tragen genauso für jedes andere eigene GraphQL-Projekt in Magento 2.