Batch-Resolver (Kapitel 20) reduzieren die Zahl der Datenbankabfragen pro Anfrage. Caching setzt eine Ebene höher an: eine komplette GraphQL-Antwort gar nicht erst neu berechnen, wenn eine identische Anfrage bereits vorliegt. Dieses Kapitel zeigt, wie Magentos Full Page Cache mit GraphQL zusammenspielt - und wo die Grenzen dieses Mechanismus liegen, gerade bei personalisierten Feldern wie is_favorite.

GraphQL-Antworten landen im selben FPC wie jede andere Seite

Magento behandelt /graphql-Antworten grundsätzlich wie jede andere HTTP-Antwort im Full Page Cache: Ein X-Magento-Cache-Id-Header wird aus Query-String, Variablen, Store und Website-Kontext berechnet, und eine identische Folgeanfrage wird direkt aus dem Cache beantwortet, ohne dass ein einziger Resolver erneut läuft.

Authentifizierte Anfragen werden nicht öffentlich gecacht

Der entscheidende Schutzmechanismus für personalisierte Felder wie is_favorite: Sobald eine Anfrage einen Authorization-Header mit einem Kunden-Token trägt (Kapitel 17), markiert Magento die Antwort als nicht öffentlich cachefähig. Ein eingeloggter Kunde bekommt also niemals versehentlich die im FPC gespeicherte "is_favorite: false"-Antwort eines anderen (Gast-)Requests serviert - Anfragen mit Kunden-Token laufen grundsätzlich immer frisch durch alle Resolver.

Cache-Tags für die eigene events-Query

Für anonyme, öffentlich gecachte Anfragen bleibt ein zweites Problem: Wird eine Veranstaltung im Admin geändert, muss der zugehörige FPC-Eintrag invalidiert werden - sonst liefert der Cache veraltete Daten. Resolver, die \Magento\Framework\GraphQl\Query\Resolver\IdentityInterface implementieren, können dafür eigene Cache-Tags an die Antwort anhängen:

<?php

declare(strict_types=1);

namespace Mironsoft\Event\Model\Resolver;

use Magento\Framework\GraphQl\Config\Element\Field;
use Magento\Framework\GraphQl\Query\Resolver\IdentityInterface;
use Magento\Framework\GraphQl\Query\ResolverInterface;
use Magento\Framework\GraphQl\Schema\Type\ResolveInfo;
use Mironsoft\Event\Model\Resolver\DataProvider\Events as EventsDataProvider;

/**
 * Resolves the events query field and tags its FPC entry per event.
 */
class Events implements ResolverInterface, IdentityInterface
{
    private const CACHE_TAG = 'mironsoft_event';

    /**
     * @param EventsDataProvider $eventsDataProvider Loads and shapes event list data
     */
    public function __construct(
        private readonly EventsDataProvider $eventsDataProvider,
    ) {
    }

    // resolve() unverändert wie in Kapitel 13/14 (siehe oben)

    /**
     * Returns the cache tags this resolved data should be invalidated by.
     *
     * @param array<string, mixed> $resolvedData The array returned by resolve()
     * @return string[]
     */
    public function getIdentities(array $resolvedData): array
    {
        $tags = [self::CACHE_TAG];

        foreach ($resolvedData['items'] ?? [] as $item) {
            if (isset($item['event_id'])) {
                $tags[] = self::CACHE_TAG . '_' . $item['event_id'];
            }
        }

        return $tags;
    }
}

Beim Speichern einer Veranstaltung im Admin (z. B. über einen künftigen Save-Controller nach dem Muster der Admin-Grids-&-Formulare-Serie) müsste das Event-Model konsequent \Magento\Framework\DataObject\IdentityInterface implementieren und denselben Tag-Präfix zurückgeben - erst dann greift Magentos automatische Cache-Invalidierung beim Speichern durchgängig.

Was Caching nicht ersetzt

Caching senkt Antwortzeiten für wiederholte, identische Anfragen - es löst nicht das N+1-Problem aus Kapitel 20 für die erste Anfrage, die den Cache füllt, und es hilft nicht bei Mutations, die naturgemäß nie aus dem Cache bedient werden dürfen. Beide Optimierungsebenen ergänzen sich, ersetzen sich aber nicht gegenseitig.

Kapitel 22 wechselt von Lese- zu Schreib-Performance-Themen: wie sich Dateien wie Bilder überhaupt über GraphQL hochladen lassen, wo der Endpunkt keine klassischen Multipart-Uploads kennt.