Beiträge

OXID implements GraphQL

(By Pierluigi Meloni, Product Manager OXID eSales AG)

APIs, Schnittstellen zwischen Systemen, Trennung von Front Ends und Back Ends, Data Consumer jeglicher Art… sind im E-Commerce wirklich nichts neues. Es gibt im E-Commerce seit Jahren kreative Lösungen für bunt zusammengestellte Systemlandschaften. Trotzdem schafft es 2019 ein Buzzword wie „headless“ wieder auf‘s Podium. Wo bis vor kurzem „headless“ noch in einem Atemzug mit REST genannt wurde, betritt nun ein weiterer Player die Bühne der weiten Öffentlichkeit. Und das völlig zu Recht. Sein Name: GraphQL.

Was ist GraphQL?

Einfach gesagt ist GraphQL nichts anderes als eine query language (Anfragesprache), welche von Facebook 2015 veröffentlicht wurde und heute auch von anderen namhaften Playern wie GitHub, Pinterest oder Twitter eingesetzt wird. GraphQL wird verwendet, um auf Schnittstellen zuzugreifen und um Datentypen für Abnehmersysteme zu spezifizieren.

Ist GraphQL besser als REST?

Im Netz trifft man auf viele Vergleiche zwischen GraphQL und REST. Man kann in Foren-Glaubensgemeinschaften unendlich lange Diskussionen darüber lesen, welches Konzept die bessere Wahl ist. Generell ist ein objektiver Vergleich schwer, da GraphQL (wie bereits erwähnt) eine query language ist und REST lediglich ein Architekturkonzept für netzwerkbasierte Software, welches als Ergebnis einer Dissertation aus dem Jahre 2000 veröffentlicht wurde. Mein Anliegen ist es nicht, hier mit noch einem GraphQL/REST Vergleich SEO Traffic zu generieren, sondern zu erläutern, warum gerade GraphQL für OXID eine interessante Wahl ist.

Warum GraphQL bei OXID?

Im OXID Ökosystem gibt es verschiedene Implementierungen von REST-Schnittstellen. Das reicht von open source bis hin zu maßgeschneiderten Entwicklungen exklusiv in Projekten. OXID selbst hat bis Dato keine offizielle REST-Schnittstelle, was vor allem daran liegt, dass die Anforderungen der unterschiedlichen Projekte an die Spezifikation von Schnittstellen oft sehr weit auseinander liegen. So sieht die Realität im Projektalltag eben aus, weswegen Versprechen von „performanten Standardschnittstellen“ im E-Commerce-Zirkus oft einen bitteren Beigeschmack haben. Probleme, die man beim Anbieten von „standardisierten“ REST-Schnittstellen antrifft, sind vor allem:

  • Performance- und Flexibilitätsprobleme durch:
    overfetching: Man erhält (möglicherweise viele) Daten, die man gar nicht unbedingt braucht. Nehmen wir als Beispiel eine Schnittstelle für user, welche als Antwort sämtliche Informationen eines user liefern würde wie Name, Geburtsdatum, Adresse, Telefonnummer, E-Mail-Adresse, usw. Das ist ein Überangebot an Informationen, wenn man beispielsweise für seine APP nur die Spitznamen der user anzeigen will. So etwas erschwert die Handhabung mit dem Antwortobjekt und kann bei komplizierteren und größeren Antwortobjekten auch unnötigerweise auf die Performance gehen.
    underfetching: Oft enthalten Antworten von Schnittstellen nicht alle Informationen, die man für einen besonderen use case gerade braucht. Nehmen wir als Beispiel einen Aufruf für ein Forum, bei dem zu einem bestimmten user eine Auflistung seiner posts und seiner follower angezeigt werden sollen. Hier müssen mit großer Wahrscheinlichkeit – anstatt einer – drei verschiedene Schnittstellen angefragt werden, nämlich die für user, follower und posts. Mehr Anfragen = schlecht für die Performance. Erschwerend könnte noch hinzukommen, dass die 3 unabhängigen Antwortobjekte noch zu einem gemeinsamen Objekt fusioniert werden müssen, was anstrengend und fehleranfällig in der Handhabung ist.
  • Versionierung der Schnittstelle: API first ist ein Ansatz, welcher diesem Problem entgegenwirken soll. Die perfekte Definition der Schnittstelle, die dann möglichst lange konstant bleibt. Die Theorie ist spitze, die Realität sieht oft anders aus. So kommen neben ungeahnten Neuerungen und Features in einem lebendigen Business auch ganz banale Dinge hinzu wie Refactorings der Datenschicht beispielsweise und zack – die Schnittstelle muss versioniert werden. Ein großes Problem bei häufiger Versionierung ist die Fehlerfindung zwischen den unabhängigen Systemen, was mitunter zum echten PITA werden kann. REST gibt leider kein einheitliches Versionierungskonzept vor, weshalb Versionierung meist im Header oder im URI selbst passiert.

GraphQL wurde unter anderem – wie auch auf der offiziellen Webseite https://graphql.org angepriesen – mit gerade jenen Intentionen entwickelt, welche genau die oben genannten Probleme adressieren:

  • Performance- und Flexibilitätsoptimierungen durch:
    Minimierung von Requests: GraphQL „bündelt“ durch das Auflösen von Abhängigkeiten der Daten untereinander verschiedene Requests in nur einem einzigen Request.
    Nur das ausliefern, was auch benötigt wird: Bei GraphQL fragt man nicht einen fixen Schnittstellen-Endpunkt nach einem starren Ergebnisobjekt an, sondern man definiert schon in der Anfrage, wie das gewünschte Ergebnis aussehen soll.
  • „Evolving APIs without version“: Aufgrund der im vorigen Punkt beschriebenen Flexibilität der Anfragemöglichkeiten, kann man einer GraphQL Schnittstelle beispielsweise problemlos neue Features hinzufügen, ohne dass diese ein angebundenes Front End sprengen würden.

Man kann zwar nicht pauschal sagen, dass „GraphQL besser als REST“ ist, denn das hängt eindeutig von den Einsatzszenarien und Anforderungen ab. Aber man kann mit Sicherheit sagen, dass GraphQL für Problemstellungen im täglichen und schnelllebigen E-Commerce Business ein absoluter Mehrwert ist!

Wir konnten in Projekten bereits erste sehr gute Erfahrungen mit dem Einsatz der GraphQL machen, weswegen wir uns entschieden haben, GraphQL in den Core des OXID eShop zu integrieren. Für die Realisierung dieses Vorhabens haben wir einen Open Innovation Ansatz gewählt.

GraphQL und Taskforce Open Innovation bei OXID

Open Innovation bei OXID!

Da GraphQL für viele Entwickler – und auch für uns – noch größtenteils Neuland ist, haben wir uns dazu entschieden, die Entwicklung gemeinsam mit verschiedensten Gruppen unseres Ökosystems anzugehen, um auf Erfahrungen zurückgreifen, und um gemeinsam Innovation vorantreiben zu können. Wir haben eine Taskforce mit Vertretern von Community, Enterprise- und Solutionpartnern, Kunden, OXID Professional Services sowie dem OXID Core Development gebildet. Diese Taskforce hat Erfahrungen und Learnings eingesetzter REST-Schnittstellen diskutiert, sowie Prioritäten und Milestones in der Anbindung von GraphQL an OXID erarbeitet.

Als Hersteller einer Standardsoftware haben wir die Philosophie, dass Innovation zum größten Teil nicht an der Basis (also in der Breite) entsteht, sondern in der Spitze. Innovative Features entstehen bei den Domänenexperten in den Projekten, in agilen Use-Cases, in A/B Tests in kleinen Szenarien im Livebetrieb, wo man mehr Spielraum für Risiken hat. Hohes Innovationsrisiko in Standardsoftware bedeutet dagegen, alle Kunden zum Testballon für Technologieexperimente zu machen, und das Risiko auf Kundenseite zu verlagern. Daher liegt unsere Verantwortung weniger darin, fertige „innovative“ Features zu produzieren, sondern darin, Freiheitsgrade und eine Basis zu schaffen, auf der Innovation entstehen kann. Erreicht diese Innovation eine gewisse Reife (Funktionalität, Stabilität, Akzeptanz), dann kann sie den Weg in die Standardsoftware finden. Genau so sind wir hier auch vorgegangen.

OXID selbst hat die Anbindung von GraphQL bereits realisiert, dokumentiert und im Rahmen der Taskforce released. Dazu gibt es best practice Beispiele, wie spezielle Routen (vgl. Schnittstellen: schemas, types, mutations) umgesetzt werden sollten. Die restlichen Mitglieder der Taskforce können auf dieser Basis die für sie relevanten Routen implementieren, welche innerhalb der Taskforce geteilt und optimiert werden. Das Ziel ist hierbei, die relevantesten Routen zu identifizieren, sie product-ready zu machen, um sie dann Stück für Stück in den Core zu überführen, bis am Ende „vollumfängliche“ Routen für den OXID eShop zur Verfügung stehen.

Pierluigi Meloni

Pierluigi Meloni war schon in der Schule dagegen. Schon damals waren Fragen wie „Warum sollte jemand so etwas überhaupt machen wollen?“ ständige Begleiter des Alltags. Das ist bis heute auch so geblieben, weswegen er als Software Architect und Requirements Engineer auf Herangehensweisen wie Domain-Driven Design schwört und seinen Fokus auf die sorgfältige Klärung des WAS richtet. Tätig in verschiedensten Branchen ist er vor knapp 3 Jahren im E-Commerce gelandet, wo das „Was“ eine besondere Herausforderung darstellt, da es meist einem anarchistischen Pool entspringt, dessen Grenzen Technikgenies und Marktschreier bilden. Humor mag er auch.

Gastblog: Mit Microsoft AX 2012 neue Wege im E-Commerce beschreiten

Stetige Informationen sind Anspruch und Bedürfnis moderner Kunden: 24 Stunden, 7 Tage die Woche. Eine zentrale Rolle spielt dabei ein gut integriertes E-Commerce-Portal. Es ist Chance und Herausforderung zugleich für Handelsunternehmen aller Art. Bieten Websites und Webshops doch Kunden eine optimale Plattform für eine selbständige Informationsversorgung. Dies bedeutet nicht nur Service am Kunden. Es entlastet auch bestehende Kundenkanäle wie den telefonischen Support oder den Verkaufsinnendienst.

Voraussetzung für den erfolgreichen Schritt in den E-Commerce

Ein wesentlicher Faktor für den Erfolg eines Online-Vertriebskanals ist die reibungslose Anbindung des Shops an das Warenwirtschaftssystem eines Unternehmens. Durch eine automatische Übertragung aller relevanten Daten werden diese zentral verwaltet. So lassen sich Prozesse effizienter gestalten. Das spart Zeit und Geld. Und nur so ist es möglich, erfolgreich und kundenfreundlich zu wirtschaften.

Mit OXID4AX wird Microsoft Dynamics AX Anwendern eine umfassende Lösung für den Einstieg in den E-Commerce geboten. Die Optimierung und Verschlankung der Arbeitsprozesse des Webshop-Betreibers gewährleisten eine schnelle Amortisation von Investitionen in den Webshop.

Zusammenspiel Microsoft Dynamics AX und OXID eShop

Unternehmen, die bereits Microsoft Dynamics AX im Einsatz haben, lassen häufig viel Zeit und Ressourcen in die unternehmensspezifische Anpassung des Systems fließen. Daher steht bei OXID4AX eine Trennung der Systeme im Vordergrund. Dennoch erfolgt eine saubere Integration. Microsoft Dynamics AX und der OXID eShop bleiben eigenständig in ihrer Logik.

OXID eShop Schnittstelle in Microsoft Dynamics AXOXID4AX ist ein Add-On für Microsoft Dynamics AX. Darin inbegriffen sind der OXID eShop sowie die Schnittstelle OXAX für eine 100 %-ige Integration des Vertriebskanals in die Microsoft ERP-Lösung. Umfangreiche Stammdaten zu Produkten und Kunden werden zentral im ERP gepflegt und stehen dem Webshop sofort zur Verfügung. In Echtzeit erhalten Shopbesucher Informationen zu verfügbaren Artikeln und aktuellen Lagerbeständen.

Ein komplexes Thema beim Betreiben eines Shops ist die Preisgestaltung. Im Rahmen von OXID4AX sind sämtliche in Microsoft Dynamics AX verfügbaren Preisstrukturen an den Shop übertragbar. Damit sind sowohl B2C- als auch B2B-Kunden individuell ansprechbar. Ausgehandelte Konditionen werden automatisch berücksichtigt.

Zudem erfolgt eine Anpassung der vorhandenen Informationen im OXID eShop Kundenportal. Neben der Bestellhistorie sind sämtliche in Microsoft Dynamics AX generierten Rechnungen im PDF-Format verfügbar. Beides wird in Echtzeit aus dem ERP-System abgerufen. Das beinhaltet auch Bestellungen, die direkt in Microsoft Dynamics AX erfasst wurden. So bleibt der Kunde vollumfänglich über seine getätigten Bestellungen auf dem Laufenden.

Was ist mit OXID4AX noch möglich?

Die Standardlösung bietet bereits eine umfangreiche Integration von Shop und ERP. Doch durch die flexible Architektur beider Systeme sind Weiterentwicklungen möglich. Dank zahlreicher, frei verfügbarer Module kann man mit der rasanten technologischen Entwicklung problemlos Schritt halten.

Vorteile und Nutzen auf einen Blick

OX4AX_tabelleFazit

OXID4AX macht die Integration eines Shops ins Microsoft Dynamics AX zum Kinderspiel. Langwierige Implementierungsphasen gehören der Vergangenheit an. Der Mehrwert einer voll integrierten E-Commerce-Lösung liegt in der Kundenzufriedenheit, Kundenbindung und langfristig im gesteigerten Umsatz. So wird der E-Commerce zum Erfolgsfaktor einer jeden Unternehmung.

Autor:

Anne-Rosenthal_blog_swAnne Rosenthal ist bei der ESYON GmbH die Spezialistin für Marketing und PMO. Bei der Entwicklung von OXID4AX war sie als PMO maßgeblich beteiligt und leistete mit der Evaluierung der Marktsituation die wesentliche Grundlage des Projektes. Als E-Commerce-Spezialistin betreut sie verschiedene Webanwendungen der ESYON GmbH aus Leipzig. Privat lebt sie ihren Beruf weiter und betreibt einen Blog rund um bunte Tassen, Familie und Leipzig.