OXID implements GraphQL

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 istGraphQLnichts 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:

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

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 Problemstellungenim täglichen und schnelllebigen E-Commerce Business ein absoluter Mehrwertist!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.

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 eineTaskforcemit 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, dassInnovation 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.