Dieses Kapitel füllt schema.graphqls aus Kapitel 4 mit der ersten eigenen Query: shopGreeting, ein bewusst simples Beispiel, das den kompletten Weg von Schema über Resolver bis zur Antwort ohne Ablenkung durch Datenbankzugriffe zeigt.

Die Query im Schema deklarieren

type Query {
    shopGreeting(
        name: String
    ): String
        @resolver(class: "Mironsoft\\GraphqlDemo\\Model\\Resolver\\ShopGreeting")
        @doc(description: "Returns a friendly greeting, optionally personalized by name")
}

type Query { ... } erweitert - genau wie extend type in Block 3 - den bereits vorhandenen Query-Typ aus Magento_GraphQl additiv um ein neues Feld. Ab Magento 2.3 kann type Query { ... } in mehreren Modulen wiederholt vorkommen, ohne Konflikt, solange die Feldnamen eindeutig sind - die Schemas werden zusammengeführt.

Den Resolver implementieren

<?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 shopGreeting query field.
 */
class ShopGreeting implements ResolverInterface
{
    /**
     * Builds a greeting string, optionally personalized with the given name.
     *
     * @param Field $field Resolved GraphQL field configuration
     * @param mixed $context Resolver context (store, customer, request headers)
     * @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 shopGreeting field
     * @return string
     */
    public function resolve(
        Field $field,
        $context,
        ResolveInfo $info,
        ?array $value = null,
        ?array $args = null
    ): string {
        $name = $args['name'] ?? null;

        return $name !== null
            ? sprintf('Hallo, %s! Willkommen bei Mironsoft.', $name)
            : 'Hallo! Willkommen bei Mironsoft.';
    }
}

Auffällig: keine Konstruktor-Dependency-Injection nötig, weil dieser Resolver keine externen Abhängigkeiten hat. Sobald echte Daten aus der Datenbank kommen (ab Kapitel 13), wandert die eigentliche Logik in eine DataProvider-Klasse, die der Resolver per Constructor Property Promotion injiziert bekommt - der Resolver selbst bleibt bewusst dünn.

Die Query testen

bin/cache-clean config

query {
  shopGreeting(name: "Team")
}

{
  "data": {
    "shopGreeting": "Hallo, Team! Willkommen bei Mironsoft."
  }
}

Skalare Rückgabewerte vs. Objekte

shopGreeting gibt einen einfachen String zurück - der Resolver liefert also direkt den Skalarwert, nicht ein Array. Sobald ein Feld einen eigenen GraphQL-Typ zurückgibt (statt eines Skalars), muss der Resolver stattdessen ein assoziatives Array liefern, dessen Schlüssel den Feldnamen des Zieltyps entsprechen - Kapitel 6 zeigt genau diesen Fall.

Kapitel 6 baut auf diesem Muster auf und führt komplexe Typen sowie eigene Input-Typen ein - der nächste Schritt weg von reinen Skalar-Feldern.