GraphQL bei OXID: Mehr Möglichkeiten mit der neuen API

Als etabliertes Shopsystem bietet OXID eShop die Erfolgsgrundlage für zahlreiche Onlinehändlerinnen und -händler. Das System selbst kann dabei als eine Art Fundament betrachtet werden, das bei Bedarf um neue Funktionen und Schnittstellen erweitert werden kann. In Sachen Erweiterbarkeit geht OXID nun neue Wege und setzt dabei auf die Abfragesprache GraphQL. Was es mit dieser auf sich hat und warum diese Kombination eine überaus sinnvolle ist, erfahren Sie in diesem Blogbeitrag.

Beim Produkt Konfigurator haben wir Features aus Microsoft Dynamics 365 Finance in Microsoft Azure nutzbar gemacht. Auf die Art lässt sich das Tool nahtlos in Ihren Onlineshop integrieren. Im Mittelpunkt der Entwicklung standen der Azure SignalR Service und Solver, eine Strategie für Produktkonfigurationsmodelle.

Jetzt, wo Funktion und Zweck von GraphQL geklärt sind, bietet es sich an, eine sich womöglich stellende Frage zu klären: Grundsätzlich ließen sich APIs auch mit REST realisieren, warum hat man sich bei OXID also für einen anderen Weg und für GraphQL entschieden?

Im Netz kursieren bereits viele Vergleiche á la GraphQL vs. REST, wobei der Direktvergleich zwischen beiden an und für sich etwas hinkt. Wie an anderer Stelle bereits erwähnt, handelt es sich bei GraphQL um eine Abfragesprache, während REST (Representational State Transfer) im Kern „nur“ ein Architekturprinzip für netzwerkbasierte Software ist.

REST APIs für OXID gibt es einige. Dabei handelt es sich entweder um Open-Source-Lösungen oder individuelle Schnittstellen im Zuge von Projekten. Die OXID eSales AG selbst hat bis heute keine offizielle REST API für die Anbindung unabhängiger Systeme veröffentlicht. Der Grund dafür liegt in der Natur von „standardisierten“ REST APIs, die im Alltag häufig mit den folgenden Problemen behaftet sind:

Overfetching: REST-APIs neigen zum Overfetching, was bedeutet, dass Sie als Ergebnis einer Anfrage mehr Informationen erhalten, als Sie eigentlich benötigen. Ein gutes Beispiel hierfür ist die Abfrage von Kundendaten: Stellen Sie sich vor, Sie erhalten auf Ihre Suchanfrage nach bestimmten Kund:innen deren Namen, Anschrift, den Kontakt eines Verantwortlichen und eine Kundennummer, obwohl Sie nur letztere in Erfahrung bringen wollten.

Underfetching: Das Pedant zum Overfetching ist das Underfetching, vor dem eine REST-API ebenfalls nicht gefeit ist. Vor allem in speziellen Anwendungsfällen kann es vorkommen, dass eine Anfrage zu wenig Informationen liefert. Wollten Sie beispielsweise zu den oben genannten Kundendaten auch noch die Bestellhistorie in Erfahrung bringen, wird sehr wahrscheinlich auch noch eine zweite Abfrage fällig, denn Sie müssten Ihre Bestellinformationen zusätzlich abrufen. Mehr Abfragen gehen zulasten der Performance, das gilt vor allem dann, wenn beide Informationen aufwendig zu einem Objekt zusammengeführt werden sollen.

Versionierung: Änderungen an bestehenden Funktionen und neue Features führen dazu, dass eine REST API im Geschäftsalltag häufig versioniert werden muss, das macht diese anfälliger für Kompatibilitätsprobleme.

GraphQL wurde genau zu dem Zweck entwickelt, diesen Problemen zu begegnen und ist eine gute Wahl, wenn es darum geht, einer Vielzahl von Anwendern eine API als Basismodul zur Verfügung zu stellen.

Minimierung von Requests: GraphQL löst Abhängigkeiten von Informationen untereinander auf und bündelt auf die Art mehrere Anfragen zu nur einem Request, was Ressourcen einspart.

Ausgabe nur relevanter Informationen: GraphQL gibt nur tatsächlich angefragte Daten zurück. So wird ein bestehendes System nicht durch zu viele Informationen aufgebläht, etwa wenn neue Features implementiert werden.

Entwickeln ohne Version: Dadurch, dass die Datenabfrage flexibel und nur auf relevante Informationen reduziert ist, lassen sich ganz einfach neue Features implementieren, ohne dass bestehende Abfragen durch diese beeinträchtigt sind. Das ermöglicht eine stetige Weiterentwicklung ohne Versionierung.

Für viele Unternehmen ist GraphQL noch ein weitgehend neues Terrain – da bildet auch die OXID eSales AG keine Ausnahme. Als Enterprise Level Solution Partner sind wir in ständigem Austausch mit dem OXID-Team und von Anfang dabei, wenn es um die Nutzung von GraphQL unter OXID geht. So nahmen unsere Entwickler beispielsweise an den OXID Coding Days teil, einem Partnerevent, bei dem es darum ging, auf Basis des GraphQL-Moduls einen headless Onlineshop zu realisieren. Nähere Informationen dazu erfolgen in Kürze.

Sie planen, OXID eShop für Ihren Onlineshop zu nutzen oder Ihre bestehende OXID-Lösung zu erweitern? Die ESYON ist auf den Umgang mit OXID eShop und die Individualentwicklung spezialisiert. Zu unseren Lösungen zählen zum Beispiel die OXID eShop App und die P2O-Schnittstelle, mit der es möglich ist, Perfion PIM an OXID anzubinden.

In einem unverbindlichen Ersttermin besprechen wir die Anforderungen für Ihr Projekt.