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.

OXID Responsive Theme Flow

OXID eShop – Die technische Basis für gelungenes Content Marketing

Dieser Beitrag ist eine kleine Erinnerung an die OXID Commons 2016. Mein persönliches Highlight war der Track „Shopmanagement – Was braucht mein Shop, damit es dem Kunden gut geht?“ Hier habe ich in der Hands-on Session „Flow und Visual CMS“ zwei neue, zentrale Werkzeuge des OXID eShop vorgestellt.
Bereits in der Keynote merkte CEO Roland Fesenmayr an, man habe es „fast verpennt“, den OXID-Shopbetreibern standardmäßig ein Responsive Theme an die Hand zu geben. Aber eben nur fast!

Entsprechend groß war die Resonanz: pünktlich zum Vortragsbeginn war der „Saal Völler“ randvoll mit interessierten Besuchern, die sich früh genug vom Flammkuchen und den anderen Leckereien des vorzüglichen Caterings lösen konnten.

Mit Flow und Visual CMS reagieren wir auf die zahlreichen Rückmeldungen von Kunden und Partnern zu den geforderten Marktanforderungen an moderne Shopsysteme. Gemeinsam mit dem Entwicklungspartner digidesk media solutions wurden die beiden Tools entwickelt, von denen im Vortrag zunächst das Responsive Theme Flow beleuchtet wurde.

OXID Responsive Theme Flow schafft Verbindung

OXID Responsive Theme FlowIn den neuen Shopversionen 5.3 (PE/EE, liegt bereits in der Beta vor) und 4.10 (CE) ist das heiß ersehnte Responsive Theme enthalten – als Parent Theme und unabhängig zum bisherigen Standardtheme Azure, das aber weiterhin mit dabei ist. Dadurch ist der Shop direkt für alle gängigen Endgeräte optimiert und den zugehörigen Bildschirmauflösungen gewappnet. Das dürfte die kleineren Shopbetreiber, Agenturen und Partner gleichermaßen erfreuen, denn wir liefern dadurch eine Out-of-the-box-Lösung auf Bootstrap-Basis zur Anpassung und Erweiterung für die Kunden.

Neben dem full responsive Design, bringt Flow noch allerhand weitere Vorteile mit sich. In den Theme-Einstellungen können mit wenigen Mausklicks und ohne tiefere technische Kenntnisse gleich mehrere Bereiche konfiguriert werden:

  • Im Bereich Design können u. a. das Logo und das Hintergrundbild ausgetauscht sowie diverse Elemente der Oberfläche ein- oder ausgeblendet werden.
  • Im Bereich Social Media können die gängigen Kanäle wie Facebook, Google+ und Twitter bis hin zu YouTube und dem Unternehmensblog (WordPress) verlinkt werden.
  • Mit einem hörbaren, freudigen Aufatmen im Saal wurde die enthaltene API zur Kenntnis genommen. Damit können Artikel direkt in Google Shopping platziert und in Google Analytics überwacht werden. Dies geschieht über eine Tracking-ID, welche die Verknüpfung zum gewünschten Google-Konto herstellt.

Da der Shop nun also full responsive daherkommt, steigen die Erwartungen der Shopbetreiber, Inhalte auch Responsive darzustellen. Zurecht! Storytelling ist ein gerne genutztes Buzzword. Mit dem Visual CMS bedient wir, was gemeinhin darunter verstanden wird. Der Shop muss informieren, aufklären und unterhalten… in jedem Fall aber überzeugen. Dies ist nur dann möglich, wenn der Einkäufer visuell und emotional überzeugt wird. Schnell. Nachhaltig. Und über sein Smartphone. Dieser Aufgabe stellt sich Visual CMS als umfangreiches, voll integriertes und intuitives E-Commerce CMS.

OXID Visual CMS – Die Basis für Content-Welten und starkes Storytelling

OXID Visual CMSTechnisch ist der Visual CMS Editor zwar nach wie vor ein Modul, wird allerdings seit der PE/EE 5.3 Beta in der 1.0.0 Beta im Standard mit ausgeliefert. Selbstverständlich bleibt der bisherige CMS-Editor erhalten und auch die Standardbeiträge bleiben unberührt, lassen sich künftig jedoch auch mit dem Visual CMS bearbeiten.

Einblicke in das Visual CMS Backend

Gemäß des Ansatzes als Storytelling-Tool findet sich der gefeierte neue Menüpunkt unter „Kundeninformationen“ und legt nach Klick eine ansprechende, angenehm große Arbeitsfläche frei. Schon auf den ersten Blick fällt die hohe Usability auf, die digidesk media solutions bei der Konzipierung befolgte. In der linken Spalte lassen sich sämtliche Metainformationen des Beitrags wie Titel, ID, Sichtbarkeit, Typ uvm. konfigurieren, während in der rechten, breiten Spalte der Inhalt mit so genannten „Widgets“ erstellt werden kann.

How-to Content-Welt Kiteboarding

Im weiteren Vortrag wurde zu Demozwecken exemplarisch ein Beitrag namens „Entdecken Sie Kiteboarding“ verfasst, anhand dessen die Einfachheit der Beitragserstellung in Visual CMS demonstriert wurde. Ziel war eine Info-Seite über Kiteboarding, welche über einen Menüpunkt des Topmenüs aufgerufen werden kann und in deren formatiertem Fließtext konkrete Artikel, Artikelkategorien und vor allem ausdrucksstarke Bilder eingefügt sind. Dadurch soll die gut erreichbare Seite umfassend über das Thema Kiteboarding informieren und an den richtigen Stellen zu Artikeln führen, welche letztendlich den Weg in den Warenkorb finden sollen.

OXID Visual CMS, Hero WidgetZunächst wurde ein Hero-Widget über die volle Breite als Einstieg in Landingpage erstellt. Es erlaubt die Platzierung von Textbausteinen und einer verlinkten Call-to-Action-Schaltfläche über einem zentrierten, fixierten Hintergrundbild. Darunter informiert ein Text-Widget über den Trendsport. In diesem wurden passend zum Text darüber die beiden Artikelkategorien Kiteboards und Wakeboards mit je max. vier Artikeln verschachtelt und sauber angeordnet angezeigt. Drei Kategorie-Widgets verwiesen auf die übrigen Kategorien unter dem Überbegriff Kiteboarding. Mittels Spacer-Widgets zur Auflockerung wurde die Seite komplettiert. Nachdem die Seite zufriedenstellend aussah, konnte sie aktiv geschaltet und dadurch technisch als Kategorie und optisch als zusätzlicher Menüpunkt im Shop eingebunden werden. Dieser führte beim anschließenden Test zur frisch erstellten Seite und erzeugte ein Aha-Erlebnis im Saal.

Ein Tool – Ungeahnte Möglichkeiten

Visual CMS ist ein ideales Werkzeug für kleinere Shopbetreiber, um mit attraktiven Content-Welten und Storytelling den Kunden zu binden. Außerdem stellt es eine perfekte Grundlage für Agenturen und Partner dar, welche durch die Erstellung von kundenindividuellen Widgets die Shopbetreiber darin unterstützen. Der Kunde erhält nach nur wenigen Angaben ein konformes, CI-gerechtes und personalisiertes Widget, das jeder Laie bedienen kann.

Per Bordmittel erlaubt Visual CMS außerdem das Vorbereiten von zeitlich geschalteten Beiträgen, wodurch bspw. schon im Januar die Erstellung einer Landingpage oder Kampagne für das Sommer- oder Herbstgeschäft möglich ist. Per Einstellung eines Zeitraums kann dieser Beitrag dann statt eines anderen, sichtbaren Beitrags eingeblendet und nach Ablauf der Sichtbarkeit auch wieder ausgeblendet werden.

Lesen Sie hier mehr zum Vortrag „Maßgeschneiderte Kundenlösungen mit Visual CMS“ von Pierluigi Meloni von OXID eSales und Pascal Claisse von digidesk media solutions Diese behandelte im Detail, wie kundenindividuelle Widgets erstellt werden können.

Fazit – Mit starken Inhalten und Authentizität gegen Amazon, Zalando und Co

Schlussendlich bleibt festzuhalten, dass mit Flow und Visual CMS zwei top Werkzeuge den Weg in den Shop-Standard fanden, die mit wenigen Klicks jeden Händler zum Kommunikationsprofi auf allen Endgeräten werden lassen. Kleinere Shopbetreiber schaffen durch die schnelle und einfache Bedienung für ihre Kunden maßgeschneiderte Landingpages und Kampagnen. Partnern und Agenturen eröffnen sich ganz neue Verdienstmöglichkeiten, in dem Sie für größere Shopbetreiber kundenindividuelle Erweiterungen bieten.

Autor

SW_StephanStephan Wehrle ist Diplom-Wirtschaftsinformatiker (BA) und sammelte jahrelange Erfahrung als Projektmanager in den Bereichen BPM und Asset Management, bevor er als Technical Presales Consultant bei der OXID eSales in den E-Commerce wechselte. Dort agiert er als verlängerter Arm des Vertriebs mit den Schwerpunkten B2B und Visual CMS.