OXID GraphQL API - ein Blick hinter die Kulissen der OXID Kernentwicklung
Von Häusern und Software
Darf ich mich vorstellen: Heike, seit 2007 bei OXID eSales AG in der Softwareentwicklung tätig, seit 2014 Mama von Zwillingsmädels und arbeite seit 2015 von Hamburg aus im Homeoffice.
Den Corona Lockdown haben wir zusammen mit unseren bald Schulkindern daheim im Homeoffice verbracht. Was besser lief als erwartet, zumindest was die Entscheidung anging, dass die Wohnung auf Dauer zu klein ist, die Tatsache, dass zwei von drei Balkontüren klemmen nervt und der Setzriss im Arbeitszimmer immer größer wird. Neubau, Erstbezug, 2014. "Buggy as hell", halt.
Wir suchten und fanden neue wohnliche Herausforderungen. Älteres Haus mit Charme und ein paar Macken aus den 1920ern, Erweiterung aus den 60ern, Kernsanierung 2013. Aber immerhin es #stehtnochda.
Naja, und dann kam die Anfrage, diesen Blogpost vorzubereiten. Und damit wären wir beim Thema:
Der OXID eShop ist ja auch ein über die Jahre gewachsenes 'altes Haus', die Kernsanierung ist im Gange und man muss ab und zu herausfinden, wie es genau unter dem Putz tickt. Aber #läuft ja. Strategie: Core verschlanken, neue Features wenn möglich als Module bauen.
Die Module der GraphQL API und was man damit tun kann
Eines der schicken neuen Features ist die GraphQL API, welche momentan implementiert wird.
Wir haben sie in mehrere Module aufgeteilt, davon sind:
- https://github.com/OXID-eSales/graphql-base-module
- https://github.com/OXID-eSales/graphql-catalogue-module
bereits released.
Die Module sind OpenSource und haben geradezu paranoide Checks auf Travis und unserer Continuous Integration was Codestyle, Syntax und Testabdeckung angeht (PHPUnit, Codeception, PHPStan, Deptrac, PHP CS Fixer, Infection, nur um einige Tools zu nennen).
Eine ausführliche Entwicklerdokumentation kommt mit der nächsten Version des GrahpQL Base Moduls, diese wird dann unter https://docs.oxid-esales.com/modules/graphql/en/master/ zu finden sein.
Die Dokumentation liefert auch eine ausführliche Erklärung, wie man auf das GraphQL Basismodul aufsetzend eigene Module implementieren kann.
Wir als Shopsystem-Hersteller werden ja erst mal nur den größten gemeinsamen Nenner an Queries und Mutations implementieren. Was genau "da draußen" noch gebraucht wird, wissen diejenigen am besten, die Kundenshops umsetzen.
Coming very soon
Aktuell bauen wir ein Account-Modul (https://github.com/OXID-eSales/graphql-account-module), welches auf das Catalogue und das Base Modul aufsetzt und folgende Bereiche abdecken wird:
- Kundenkonto
- anlegen, ändern, Passwort setzen, Rechnungs- und Lieferadressen verwalten
- Bestellhistorie, Kundenkonto löschen
- Einkaufslisten (Wunschzettel, Benachrichtigungsliste, ...)
- Newsletter-Status
- Produktreviews (Review und Sterne-Rating für Produkte)
- Wunschpreise
Technisch hängen wir uns mit den GraphQL Modulen an die im Shop vorhandenen Application\Models an, auf welche dann im Infrastructure Layer der Module zugegriffen wird.
Änderungen im Shop hätten dann lediglich Anpassungen in diesem Layer zur Folge und wir stellen sicher, dass sich die GraphQL-Module analog zum bereits bekannten System verhalten.
Bestellhistorie aus dem Shop, wie man sie kennt...
... und über GraphQL mit dem Altairclient
Warum ist das besser?
Über die GraphQL API können ganz gezielt Daten aus dem Shop abgefragt (Query) oder Änderungsanfragen gestellt (Mutation) werden.
Das Verhalten ist klar definiert, da der Server keine Informationen des Clients verwendet außer den in der aktuellen Anfrage enthaltenen (stateless). Anfrage rein, Antwort zurück, und immer nur die Daten abfragen, die wirklich benötigt werden. Im bisherigen Shop Frontend sind aufeinanderfolgende Requests durch eine serverseitige Session/Session Cookies verknüpft, das ist für die GraphQL API nicht mehr nötig.
Wird die GraphQL API erweitert, wird das vorhandene Umsetzungen nicht zerstören. Neue Queries und Mutations 'kommen halt dazu' und falls vorhandene Datentypen erweitert werden, stört das vorhandene Abfragen nicht. Frontend und Backend sind endlich klar trennbar.
Ich freue mich schon darauf, irgendwann in einem Liveshop einen kompletten Checkoutprozess nur über den AltairClient auszuführen.
Wie es weiter geht
Das nächste Modul der OXID GraphQL API wird sich um den Checkout-Prozess drehen. Wir sind bereits fleißig am Spiken (für die Non-Techie-Leser: die Entwickler haben gerade eine Menge Spaß damit
herauszufinden, wie das alles am besten umgesetzt werden kann).
Webinar "OXID goes headless: GraphQL für Modulentwickler"
Alles, was Entwickler zum Release der GraphQL API wissen müssen:
Unser Webinar für Modul-Entwickler