API Platform generiert aus jeder Ressource automatisch Queries und Mutations, doch sobald eine Aktion mehrere Ressourcen kombiniert oder Echtzeit Updates gefragt sind, braucht es einen eigenen GraphQL Resolver. Dieser Artikel zeigt, wie Query Resolver, Mutation Resolver mit dedizierten Input Klassen und Mercure basierte Subscriptions in API Platform zusammenspielen.
Ein Feld einfach aus dem Schema zu löschen ist keine Deprecation, sondern ein Breaking Change. Ein sauberer GraphQL Deprecation Workflow markiert Felder mit der @deprecated-Direktive, misst ihre tatsächliche Nutzung und entfernt sie erst, wenn die Daten zeigen, dass kein Konsument mehr betroffen ist.
Sobald mehrere Knoten in einer Group Replication gleichzeitig Schreibzugriffe akzeptieren, entscheidet die Certification-based Conflict Detection darüber, welche Transaktion gewinnt und welche zurückgerollt wird. Wer diesen Mechanismus nicht versteht, baut Anwendungen, die im Multi-Primary-Betrieb regelmäßig an scheinbar zufälligen Rollbacks scheitern.
Eine Schema-Migration ohne klare Versionierung und Rollback-Plan wird auf einer großen produktiven Tabelle schnell zum Risiko. Dieser Beitrag zeigt Namenskonventionen für Migrationsdateien, den Unterschied zwischen forward-only und reversible Migrations, das Expand-Contract-Pattern und sichere Vorgehensweisen für NOT NULL-Spalten an Tabellen mit Millionen Zeilen, mit konkretem SQL für jeden Schritt.
Fuse.js ist eine leichtgewichtige JavaScript-Bibliothek für clientseitige Fuzzy-Search, die sich sehr gut mit dem statisch generierten Content-Index von Nuxt Content kombinieren lässt, ohne dass ein externer Suchdienst wie Algolia betrieben oder bezahlt werden muss. Wer eine überschaubare Anzahl an Content-Seiten hat, kann damit eine tippfehlertolerante Suche direkt im Browser umsetzen, inklusive Gewichtung von Titel gegenüber Fließtext und ohne zusätzliche Serverinfrastruktur.
In Magento 2 ist die Frage nach REST oder GraphQL selten rein technisch. Beide Ansätze sind nützlich, aber sie passen zu unterschiedlichen Frontends, Datenflüssen und Teamstrukturen. Gute Entscheidungen entstehen deshalb aus Use-Cases, nicht aus API-Mode.
1. Was REST und GraphQL in Magento 2 jeweils gut können
REST vs GraphQL Magento 2 ist keine Frage von alt gegen neu, sondern von Zugriffsmuster gegen Zugriffsmuster. REST ist stark, wenn klare Ressourcen, etablierte Integrationen und stabile Endpunkte
Ein eigener Magento 2 REST Endpoint braucht mehr als nur eine URL. Entscheidend sind Service Contract, webapi.xml, ACL, saubere Dependency Injection und eine klare Authentifizierungsstrategie.
Persisted Queries lösen zwei Probleme gleichzeitig: Sie reduzieren die übertragene Datenmenge und schließen eine Sicherheitslücke, die in öffentlichen GraphQL-APIs oft übersehen wird. Wer beliebige Queries akzeptiert, gibt Angreifern freie Hand. Wer nur bekannte Queries erlaubt, gewinnt Kontrolle — ohne Flexibilität komplett zu opfern.
Anfragen wie bester Fahrradladen in meiner Nähe folgen einer anderen Logik als generische Informationsfragen, weil KI-Suchmaschinen dafür Echtzeit-Standortdaten statt reinen Fachcontent benötigen. Google Business Profile, LocalBusiness-Schema und konsistente Kontaktdaten werden dadurch zu eigenständigen GEO-Hebeln, die sich klar von der generischen GEO-Strategie unterscheiden. Dieser Artikel zeigt, wie KI-Systeme bei lokalen Anfragen Quellen auswählen, wie das Zusammenspiel mit Google Business Profile funktioniert und wie sich das in einem Magento-Multi-Store mit mehreren Filialen praktisch umsetzen lässt.
Read Replicas versprechen mehr Lesekapazität ohne größere Hardware, doch wer Leseanfragen blind auf Replicas verteilt, handelt sich veraltete Daten und schwer reproduzierbare Bugs ein. Erst ein bewusstes Read/Write-Splitting mit klarer Konsistenzstrategie macht MySQL Read Replicas zu einem verlässlichen Baustein der Skalierung.