Bisher hat jede eigene Query einen komplett neuen Typ deklariert. Genauso häufig - in der Praxis sogar häufiger - ist der umgekehrte Fall: ein bestehender Core-Typ wie Product, Category oder CustomerOutput soll um ein eigenes Feld ergänzt werden. Dafür gibt es extend type.

Warum nicht einfach einen neuen Typ anlegen?

Ein neuer, eigener Typ MironsoftProductExtra mit einem eigenen Feld in der Query wäre zwar technisch möglich, würde aber jeden Client zwingen, eine zweite, komplett getrennte Query für zusammengehörige Produktdaten abzusetzen - genau das Underfetching-Problem aus Kapitel 1, das GraphQL eigentlich lösen soll. extend type Product { ... } hängt das eigene Feld stattdessen direkt an den bestehenden Typ, sodass es in derselben Query wie alle anderen Produktfelder abgefragt werden kann.

Die extend-type-Syntax

extend type Product {
    mironsoft_badge_text: String
        @resolver(class: "Mironsoft\\GraphqlDemo\\Model\\Resolver\\Product\\BadgeText")
        @doc(description: "Custom marketing badge text shown on the product tile")
}

Wichtig: Product ist selbst bereits eine Erweiterung von ProductInterface aus Magento_CatalogGraphQl - Magentos eigener Produkttyp entsteht durch dasselbe Muster, das hier verwendet wird. Ohne die in Kapitel 4 gesetzte Modulabhängigkeit auf Magento_CatalogGraphQl würde extend type Product ins Leere laufen, weil der Basistyp zum Ladezeitpunkt noch nicht existiert.

Resolver für erweiterte Felder

<?php

declare(strict_types=1);

namespace Mironsoft\GraphqlDemo\Model\Resolver\Product;

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

/**
 * Resolves the custom mironsoft_badge_text field on the Product type.
 */
class BadgeText implements ResolverInterface
{
    /**
     * Derives a marketing badge from the resolved product model.
     *
     * @param Field $field Resolved GraphQL field configuration
     * @param mixed $context Resolver context
     * @param ResolveInfo $info GraphQL resolve tree info
     * @param array|null $value Parent Product resolver's value
     * @param array|null $args Arguments passed to this field
     * @return string|null
     */
    public function resolve(
        Field $field,
        $context,
        ResolveInfo $info,
        ?array $value = null,
        ?array $args = null
    ): ?string {
        /** @var Product|null $product */
        $product = $value['model'] ?? null;

        if ($product === null || !$product->getData('is_new_arrival')) {
            return null;
        }

        return 'Neu eingetroffen';
    }
}

Der entscheidende Unterschied zu Kapitel 5 und 6: $value ist jetzt nicht leer. Es enthält, was der Eltern-Resolver (Magento\CatalogGraphQl\Model\Resolver\Products) für das aktuell verarbeitete Produkt geliefert hat - inklusive dem Schlüssel model, unter dem viele Core-Resolver das komplette Produktmodell für nachgelagerte Feld-Resolver bereitstellen. Kapitel 10 geht auf $value im Detail ein.

Die erweiterte Query abfragen

query {
  products(filter: { sku: { eq: "24-MB01" } }) {
    items {
      name
      mironsoft_badge_text
    }
  }
}

Für den Client ist mironsoft_badge_text ununterscheidbar von einem nativen Core-Feld - genau das ist der Sinn von extend type: eigene Erweiterungen fügen sich nahtlos in bestehende Typen ein.

Kapitel 9 vertieft dieses Muster an drei konkreten, besonders häufig erweiterten Core-Typen: Produkt, Kategorie und Kunde.