Update vom 08.12.2020: Die praktische Erfahrung aus mehreren Projekten hat gezeigt, dass der PWA-Ansatz aus unserer Sicht nicht für alle Magento-Projekte geeignet ist. Wir haben daher mit Hyvä einen neuen Ansatz für ein performantes und v.a. einfacheres Frontend entwickelt. Mehr Informationen zu Hyvä Themes gibt es hier:

Dies ist Teil 3 einer Artikelserie zum Thema „PWA“. Wenn Sie mehr über PWA für Magento im Allgemeinen wissen wollen, lesen Sie am Besten zunächst den ersten Teil der Artikelserie: PWA: Ein neues Frontend für Magento 2. Wenn Sie mehr über DEITY, das Unternehmen, und was integer_net damit zu tun hat, wissen wollen, lesen Sie PWA und Magento: Über DEITY.

Hier geben wir Ihnen einen breiten technischen Überblick über die DEITY-Software.

Das Herz von DEITY ist eine node.js-Anwendung mit einer geteilten Codebasis für Client und Sever. JavaScript-Entwicklern wird das sehr vertraut vorkommen. Als Standard-Technologie profitiert die node.js-Anwendung deutlich vom riesigen node/npm-Ökosystem. Der Kern selbst ist ein npm-Modul, das als Abhängigkeit in die eigene Anwendung integriert werden kann. Aktuell werden einige Funktionen extrahiert, sodass es am Ende einen Bausatz kleinerer Module geben wird, damit die einzelnen Integrationen (Magento, WordPress, Suchmaschinen etc.) optional angefordert werden können.

Warum node.js? Die node.js-Event-Loop-Architektur stellt ein schnelles Backend zur Verfügung, das parallele Anfragen verarbeiten kann. Es gibt keinen Overhead beim Start eines Prozesses wie in traditionellem PHP, wodurch die Antwortzeit schneller ist als Magento je für dynamische Inhalte sein kann, z.B. ohne Varnish. Dazu kommt, dass eine geteilte Codebasis in der gleichen Sprache für das Browser-Frontend und das Server-Backend zu reibungsloser Frontend-Entwicklung führt, entkoppelt vom PHP-Code des Magento-Backends.

Als Bibliothek für eine komponentenbasierte Benutzeroberfläche wurde React gewählt, zusammen mit Redux für die Status-Verwaltung.

Architektur-Diagramm

Die DEITY-Architektur

Das entkoppelte Frontend kann daher praktisch ohne spezifische Magento-Kenntnisse umgesetzt werden.

Kernfunktionen

Mit DEITY erhält man eine Single Page App (SPA), was sich dank dynamischer URL-Wechsel und zusätzlichem serverseitigem Rendering aber dennoch natürlich im Browser anfühlt. Dazu ist es suchmaschinenfreundlich. Als Randnotiz: Der Google-Crawler kann JavaScript ausführen, der Code muss aus SEO-Sicht also nicht mehr serverseitig generiert werden.

Anfragen an die node.js-Middleware werden an die entsprechende Backend-API weitergegeben. DEITY liefert bereits Schnittstellen zu Magento 2, zu WordPress und zu Algolia (für die Suchfunktion) mit. API-Antworten werden in node.js gecacht, um den Flaschenhals der relativ langsamen Magento-REST-API zu entschärfen.

DEITY hat einen voll funktionsfähigen Checkout mit PayPal und Kreditkartenzahlung über Adyen, einen international operierenden niederländischen Zahlungsdienstleister. Die Kreditkartenzahlung ist ohne den Einsatz von iFrames realisiert. Wie man es von PayPal und anderen Zahlungsdienstleistern kennt, bestätigt der Kunde seine Zahlung auf einer externen Seite.

Backend

DEITY nutzt eine Service-orientierte Architektur (SOA). Backend-Dienste sind miteinander und mit dem Frontend über APIs verknüft. Aktuell wird Magento für Katalog und Checkout eingesetzt, WordPress für Blogartikel und CMS-Seiten, und Algolia für die Suche. Ein WordPress-Plugin, das WordPress mit der Magento-API verbindet, ermöglicht es, Produkt-Widgets zu Blogartikeln hinzuzufügen.

In Zukunft wird da allerdings noch mehr passieren. DEITY baut eine Partnerschaft mit Dare.IT auf, um ein komplettes Sortiment von SOA-Lösungen („DEITY Enterprise“ genannt) anbieten zu können. Dies soll unter anderem Kunden-, Bestellungs- und Lagerverwaltung ermöglichen, insbesondere in den Bereichen, wo Magento keine für den Enterprise-Bereich ausreichenden eigenen Möglichkeiten besitzt.

DEITY Enterprise-Anbindungen

DEITY Enterprise-Anbindungen

Backend-Anbindung: Magento API

Um effektiv mit Magento zusammenzuarbeiten, musste die REST-API deutlich erweitert werden. Zum aktuellen Zeitpunkt gibt es 24 neue und 6 überschriebene API-Endpunkte. Die meisten hängen mit dem Kundenkonto, dem Checkout und Zahlungen zusammen. Wo es möglich ist, stellt das Magento-Modul fehlende Daten über Extension-Attribute bereit, anstatt die API zu überschreiben.

Zusammen mit Óscar Recio Soria, Maintainer des Magento-Repositories auf Github und Top-3-Contributor 2017, arbeiten wir daran, das API-Modul so weit wie möglich standardkompatibel zu machen, mit dem Fernziel, einen Großteil davon Magento über Pull Requests zugänglich zu machen. Bis dahin wird das Modul separat veröffentlicht, sodass es als Grundlage für ein „Headless“ Magento genutzt werden kann, sogar ohne den Einsatz von DEITY.

Für die Zahlung über Adyen gibt es ein separates Magento-Modul, das die API des offiziellen Adyen_Magento-Moduls erweitert.

Backend-Integration: WordPress-API

Die WordPress-API ist bereits von Haus aus sehr nützlich. Dennoch wurden einige Ergänzungen gemacht, um beispielsweise mehrere Sprachen (über das WPML-Plugin), benutzerdefinierte Felder (über das ACF-Plugin), eigene Menüs und beliebte Artikel zu unterstützen oder Artikel auf Basis einer URL zu erhalten.

Für WordPress existiert ein DEITY-Composer-Projekt-Template, das alle notwendigen Plugins beinhaltet.

Backend-Integration: Suche

Suchanfragen können direkt an Algolia weitergegeben werden. Algolia ist ein unabhängiger Dienst, der bereits ein Magento-Modul hat, das benutzt werden kann, um die Produkte aus Magento zu indizieren. Wir planen, in Zukunft auch Solr stattdessen anzubieten, für Händler, die ihre Such-Datenbank selbst hosten wollen oder stärkere Anpassungen benötigen, als Algolia ermöglicht. Die überarbeitete Architektur unserer IntegerNet_Solr-Erweiterung vereinfacht uns die Anbindung an ein neues Frontend.

Projekt-Setup und Entwicklung

Das Aufsetzen eines neuen DEITY-Projekts ist ein geradliniger Vorgang. DEITY bietet ein Template für das Scaffolding-Tool Yeoman. Nach der Installtion von Yeoman und des Templates geben Sie

auf der Kommandozeile ein und folgen den Anweisungen auf dem Bildschirm. Wenn das Template aktualisiert wurde, können Sie den Generierungsbefehl erneut im aktiven Projekt ausführen und interaktiv auswählen, welche Aktualisierungen angewendet werden sollen.

Dies ermöglicht uns einen Schnellstart für die Entwicklung eines Projektes, basierend auf dem Standard-Theme. Alternativ kann natürlich auch ein eigenes Frontend von Grund auf aufgebaut werden, in dem die vom DEITY-Kernmodul bereitgestellten Komponenten eingesetzt werden.

Yeoman und das DEITY-Theme haben bereits viele Abhängigkeiten. Üblicherweise werden diese bereits auf Ihrem System installiert sein (z.B. Python), solang es sich nicht um ein minimales Linux handelt. Ich habe ein Docker-Image erstellt, auf dem alles bereits vorinstalliert ist. Mit Einsatz des Images können Projekte ohne zusätzliche Abhängigkeiten aufgesetzt werden. Es basiert auf dem offiziellen node.js-Container und kann ebenfalls verwendet werden, um DEITY ohne weitere Vorbereitungen zu installieren. Sobald DEITY veröffentlich wird, werden wir auch dieses Image veröffentlichen – gut möglich, dass es das offizielle Image wird.

Um das Frontend zu entwickeln, muss man Magento (oder WordPress) nicht lokal installiert haben, da nur die API verwendet wird und die Werkzeuge unabhängig von Magento sind. Eine auf einem Server betriebene Entwicklungsinstanz ist vollkommen ausreichend.

Die Hot-Reload-Funktion von React sowie das node.js-Backend geben sofortige Rückmeldung an den Browser. Das sollte heutzutage nicht unbedingt erwähnt werden müssen, aber wenn Sie bisher mit dem Standard-Frontend von Magento arbeiten müssen, wird es einen großen Unterschied machen.

Aktueller Stand

DEITY ist als agenturinternes Projekt bei Hatimeria gestartet und wurde seit 2017 für mehrere E-Commerce-Projekte wiederverwendet und weiterentwickelt. In der aktuellen Landschaft der PWA-Frontends hat nur FrontCommerce eine ähnliche Reife. Nebenbei bemerkt hat FrontCommerce nicht nur eine ähnliche Vergangenheit, sondern auch eine ähnliche Architektur (und ein nettes Video darüber). Die Business-Strategie ist allerdings sehr unterschiedlich; FrontCommerce wird proprietär (also ohne frei verfügbaren Quellcode) bleiben und auch in Zukunft Lizenzkosten verlangen, während DEITY ein Modell ähnlich wie Magento anstrebt: Ein OpenSource-Kern mit zusätzlichen kostenpflichtigen Enterprise-Funktionen.

Vor diesem Hintergrund wird deutlich, dass DEITY als „Minimum Viable Product“ mit geschäftskritischen Funktionen (wie Online-Zahlung) gestartet ist und mit diesen auch in Produktivsystemen einsetzbar ist. Andererseits ist noch einiges an Arbeit zu tun, bevor es als OpenSource veröffentlicht werden kann. Hier macht sich der agenturinterne Hintergrund des Projekts bemerkbar: Nur so viel Abstraktion wie notwendig; Funktionen, die von den Referenzkunden nicht benötigt wurden, wurden nicht implementiert; und relevante Änderungen konnten ohne Rücksicht auf Rückwärtskompatibilität durchgeführt werden.

Aktuell ist die oberste Priorität des DEITY-Entwicklungsteams die Vorbereitung zur OpenSource-Veröffentlichung. Hiermit sind keine neuen Funktionen gemeint, sondern Punkte wie die Stabilität der API, Modularität, Erweiterbarkeit und ein Security Audit.

Änderungen in der Architektur sind notwendig, um Shop- und Blogmodule als separate Pakete auszugliedern, und um die Frontend-API auf den Wechsel zu GraphQL vorzubereiten. DEITY möchte nicht die gleichen Fehler wie Magento mit dem 2.0-Release machen und ein halbfertiges Produkt ausliefern, und anschließend keine großen Änderungen mehr durchführen können, aber dennoch regelmäßig die Rückwärtskompatibilität verletzen. Early Adaptors sollten nicht bestraft werden!

 

Fabian Schmengler

Author: Fabian Schmengler

Fabian Schmengler ist Diplom-Informatiker und Magento Entwickler bei integer_net. Seine Schwerpunkte sind Backend-Entwicklung, Konzeptionierung und Test-Automatisierung. Seit 2011 ist er Magento Certified Developer, seit 2014 Magento Certified Solution Specialist.