OXID implements 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.

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.

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.

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.