50.000 Produktdatensätze, ein PIM im Hintergrund, ein Headless-Frontend vornedran – und eine API, die alles lesen, aber fast nichts schreiben kann. Wer mit Magento 2 GraphQL arbeitet, kennt dieses Paradoxon: Die Schnittstelle, mit der Adobe seine Storefront-Zukunft baut, bleibt beim Datenimport stumm. Seit Version 2.3 liefert GraphQL saubere Queries für Produkte, Kategorien und Preise, doch der Rückweg – Daten in den Shop schreiben – ist out of the box bis heute nicht vorgesehen. 2026 ist der native Import in Open Source und Adobe Commerce noch immer eine CSV-Datei, die per Drag-and-drop durchs Backend wandert. Für eine Plattform, die sich als Headless-Enterprise-Lösung verkauft, ist das ein bemerkenswerter blinden Fleck.
Die gute Nachricht: Die Lücke ist geschlossen konzipiert, nicht geschlossen ausgeliefert. Magento 2 GraphQL ist erweiterbar, die Community arbeitet an Import-Lösungen, und mit einem eigenen Modul lässt sich ein produktionsreifer Import über Mutationen bauen. Dieses Tutorial zeigt, wie – und wo die Grenzen liegen.
Warum kann Magento 2 GraphQL von Haus aus nicht importieren?
Die Antwort liegt in der Architektur-Entscheidung von 2018. Adobe hat GraphQL nicht als generelle Admin-API konzipiert, sondern als schlanke Datenschicht für Progressive Web Apps. Das Schema sollte genau das abbilden, was ein React-Frontend braucht: Produktlisten, Filter, Preise, Warenkorb. Entsprechend einseitig fällt die Abdeckung aus. Queries gibt es für den gesamten Katalog, Mutationen dagegen fast nur für den Kaufprozess – Warenkorb, Checkout, Kundenkonto, Wunschliste. In Adobe Commerce kommen B2B-Mutationen für Angebote und Bestelllisten dazu. Ein Produkt anlegen? Eine Kategorie umbenennen? Fehlanzeige.
Technisch steckt dahinter ein modulares System: Jedes Magento-Modul kann über eine eigene schema.graphqls-Datei Typen, Queries und Mutationen beisteuern, Resolver-Klassen verbinden das Schema mit der Service-Schicht. Diese Architektur macht den Import per GraphQL möglich – Adobe liefert die Bausteine, nur das fertige Muster eben nicht. Die Community hat den Rest übernommen: Erweiterungen wie die Import-Export-Lösungen von Firebear Studio bringen GraphQL-basierte Jobs mit, und in den Adobe-Backlogs und Community-Diskussionen kursiert GraphQL seit Jahren als designierter Nachfolger der alternden REST-API. Tempo ist das nicht.
Der Workaround: Ein eigenes Import-Modul mit GraphQL-Mutation
Wer nicht warten will, baut die Brücke selbst. Der Weg führt über ein eigenes Modul – im Kern drei Schritte, die jede erfahrene Magento-Agentur in ein bis zwei Tagen umsetzt.
Schritt eins: das Schema. In der schema.graphqls des Moduls wird eine Mutation definiert, die ein Array von Produktdaten entgegennimmt – SKU, Name, Preis, Lagerbestand, Attribute – und ein Ergebnisobjekt mit Status und Fehlermeldungen pro Datensatz zurückgibt. Dieser Batch-Ansatz ist entscheidend: Eine Mutation, die 500 Produkte in einem Request verarbeitet, schlägt 500 einzelne Aufrufe um Längen, weil HTTP-Overhead und Session-Aufbau nur einmal anfallen.
Schritt zwei: der Resolver. Eine PHP-Klasse implementiert das ResolverInterface aus dem Magento-GraphQL-Framework und übersetzt den Input in Magento-Objekte. Bewährt hat sich der Weg über die Service Contracts – ProductRepositoryInterface statt direkter Model-Manipulation –, weil Validierung, URL-Rewrites und Attribut-Handling dann mitkommen. Fehler pro Datensatz werden gesammelt statt den ganzen Batch abzubrechen; nichts ist ärgerlicher als ein Import, der bei Satz 4.981 kippt und nicht sagt warum.
Schritt drei: die Indexer-Frage. Jeder Produkt-Save löst standardmäßig Reindex-Events aus. Bei Massenimporten heißt die Regel daher: Indexer vor dem Lauf auf „Update by Schedule“ stellen, Cron kümmert sich danach um den Rest. Wer das ignoriert, wundert sich über Importzeiten, die ins Zehnfache klettern.
Die Frage ist nicht, ob Magento GraphQL kann. Die Frage ist, wie viel davon Adobe ausliefert – und wie viel die Community selbst bauen muss.
Authentifizierung läuft über Admin-Token oder Integration-Keys, also denselben Mechanismus wie bei REST. Für den produktiven Einsatz gehören außerdem Rate-Limiting, Logging pro Batch und eine Idempotenz-Regel dazu: SKU als führender Schlüssel, Update statt Duplikat. Ohne diese Absicherung wird aus dem Tutorial schnell ein Produktivvorfall.
Wie schlägt sich GraphQL gegen REST-Bulk und den CSV-Import?
Ehrlichkeit vor Enthusiasmus: Für die meisten Massenimporte ist die eigene GraphQL-Mutation heute nicht die beste Option. Der native CSV-Import schafft auf vernünftiger Hardware Größenordnungen von mehreren tausend einfachen Produkten pro Minute. Die asynchronen REST-Bulk-Endpunkte – etwa für Produkte – legen Nachrichten in RabbitMQ ab und verarbeiten sie entkoppelt; das ist für ERP-Anbindungen seit Jahren der etablierte Weg. Eine naive Schleife einzelner GraphQL-Calls landet bei typischen Latenzen von 300 bis 500 Millisekunden pro Request bei vielleicht 150 bis 200 Schreibvorgängen pro Minute. Das ist keine Import-Pipeline, sondern ein Nadelöhr.
Geändert wird das Bild durch Batching: Eine Mutation mit 200 Datensätzen pro Aufruf relativiert den Overhead und spielt in die Nähe der REST-Bulk-Performance. Trotzdem bleibt GraphQL der aufwendigere Weg – eigenes Modul, eigene Wartung, eigene Verantwortung bei jedem Magento-Upgrade. Der Fairness halber: Genau dafür existieren die Community-Erweiterungen, die Import-Profile, Cron-Steuerung und GraphQL-Anbindung fertig mitbringen.
Die sinnvolle Einordnung sieht so aus:
- CSV-Import: Für initiale Befüllung und seltene Stapel – unschlagbar simpel, schlecht automatisierbar.
- REST Async Bulk: Für ERP- und PIM-Anbindungen mit hohem Volumen – bewährt, aber die API altert sichtbar.
- GraphQL-Mutationen: Für headless-getriebene Workflows, selektive Schreibzugriffe und Teams, die ihren Stack auf einer API vereinheitlichen wollen.
Was bedeutet die GraphQL-Lücke für den DACH-Markt?
Im deutschsprachigen Raum hat die Debatte eine zusätzliche Schärfe, und sie heißt Shopware. Der Konkurrent aus Schöppingen liefert mit seiner Sync-API eine Admin-Schnittstelle, die Bulk-Schreibvorgänge nativ akzeptiert – ein Argument, das in Agentur-Pitches gegen Adobe Commerce regelmäßig fällt. Gerade der deutsche Mittelstand, der seine Magento-Installation typischerweise an SAP, Microsoft Dynamics oder PIM-Systeme wie Akeneo und Contentserv angeflanscht hat, fragt zu Recht, warum der Import-Weg über CSV-Dateien und Warteschlangen-Konfiguration führen soll, während das Frontend längst GraphQL spricht.
Dazu kommt die Kostenrechnung. Adobe Commerce startet lizenzseitig im fünfstelligen Bereich pro Jahr; jedes selbstgebaute Import-Modul ist zusätzlicher Wartungscode auf der eigenen Bilanz. Open-Source-Nutzer zahlen keine Lizenz, tragen aber dieselbe technische Schuld. Die Erwartung, dass ein System in dieser Preisklasse eine vollständige Schreib-API mitbringt, ist keine Anmaßung – sie ist Marktstandard bei den Wettbewerbern.
Und jetzt: Bauen, kaufen oder warten?
Warten ist die schlechteste der drei Optionen. Adobes GraphQL-Roadmap hat in den vergangenen Jahren Storefront-Themen konsequent vor Admin-Coverage priorisiert, und es gibt wenig Anzeichen, dass sich das 2026 dreht. Wer einen konkreten Headless-Anwendungsfall hat – etwa ein PIM, das Produktdaten ereignisgesteuert in den Shop pushen soll – baut die Mutation nach dem oben skizzierten Muster selbst oder setzt auf eine gepflegte Community-Erweiterung. Wer schlicht Massendaten bewegen muss, bleibt bei REST Bulk und spart sich den Custom Code.
Eine Zahl zum Schluss: 200 Datensätze pro Batch, ein Request, ein sauberes Fehler-Reporting – so nah lässt sich Magento 2 GraphQL heute an einen echten Import heranführen. Aber ein Tutorial, das erklärt, wie man eine Kernfunktion selbst nachrüstet, ist zugleich ein Armutszeugnis für die Plattform. Adobe hat GraphQL als Zukunft der eigenen API-Landschaft deklariert. Solange der Datenimport auf diesem Weg Community-Arbeit bleibt, ist diese Zukunft eine Ankündigung – und Shopware erzählt im DACH-Mittelstand die fertigere Geschichte.