Code.Talks commerce special 2016 – Tag 2

Nachdem die Veranstaltung vielversprechend mit dem ersten Tag begonnen hatte, sollte sie hoffentlich genauso spannend und informativ mit dem 2ten enden.

On-site Search Design Pattern für eCommerce

Der zweite Tag startete mit einem Talk von Dr. Martin Loetzsch (Project A Ventures GmbH & Co. KG) und Krešimir Slugan (contorion.de) über die optimale Konfiguration von Elasticsearch für ein eCommerce Szenario am Beispiel von Contorion, einem Online Baumarkt.

 

contorion
Abb.: Contorion

Über den Shop werden ca. 500.000 Produkte angeboten, Contorion war die maximale Optimierung der Suche, der Facettierung und der Suchvorschläge bei der Entwicklung des Shops extrem wichtig.

Obwohl eine der Stärken von Elasticsearch in der Möglichkeit besteht (wie es auch in zahrleichen Tutorials beschrieben steht), die Daten ohne spezielle Optimierungen im Index zu speichern und trotzdem relativ gute Suchergebnisse zu erzielen, gibt es großen Spielraum für Optimierungen.

Drei gute Gründe sprechen für eine Anpassung der Datenstruktur, nämlich

  • Bei Elasticsearch Abfragen müssen die abzufragenden Attribute explizit angegeben werden
  • Die unterschiedliche Verwendung eines Attributs in einer Abfrage verlangt einen entsprechende Formulierung
  • Wenn neue Attribute hinzukommen muss das Mapping ständig erweitert werden

Aus diesen Umständen entseht in vielen Projekten eine hohe Komplexität, was dazu führt, dass häufig nicht das gesamte Potenzial ausgeschöpft wird.

Verwendungsorientiertes Schema-Design und Dokumentenstruktur

Um die Komplexität so niedrig wir möglich zu halten empfehlen die Referenten eine Dokumentenstruktur und ein Schema-Design, das sich an der Verwendung der Attribute in den Suchoperationen orientiert, wie z. B. die folgende Struktur eines Dokumentents mit Produktdaten

1

2

Hierbei werden zwar viele Daten redundant übertragen, da diese aber in den unterschiedlichen Abfragen für Volltextsuche, Auto-Suggest oder Facetten in anderer Form benötigt werden, werden dadurch später die Abfragen sehr viel einfacher.

Generische Facetten

Eines der am häufigsten im eCommerce eingesetzten Elastisearch Features ist sind Facetten. Bei der Implementierung einer facettierten Suche spielen insbesondere die passende Aggregationen eine große Rollen, wobei hier auch die größten Fehler gemacht werdend können. Anstatt, wie häufig umgesetzt, die Attribute über ein Feld zu Indexieren

Bildschirmfoto 2016-04-26 um 10.28.00

 

profitiert die facettierte Suche von der Verwendung des Nested Datatype

Bildschirmfoto 2016-04-26 um 10.28.52

 

Die Filterung und Aggregation derartiger Dokumente muss zwar entsprechend angepasst werden, dadurch wird es aber möglich

  • ein Schema zu definieren, das das einfach uns schnelle Handling von Facetten unterstützt
  • die Abfragen einfach und wartbar zu halten

Volltextsuche

Ebenso eine zentrale Rolle spielt die Volltextsuche. Hier wirkt sich insbesondere die Textanalyse auf die Qualität der Suchergebnisse aus. Hierzu bietet das Elasticsearch Analysis Module einen Set von Default Analyzern. Insbesondere für die deutsche Sprache bietet es sich jedoch ein, einen angepassten Analyseprozess zu implementieren. Während des Prozesses wird der zu indizierende Text in sogenannte Tokens zerlegt, z. B. anhand von Leerzeichen. Diese Tokens werden anschließend an Filter übergeben, welche das Token löschen, splitten oder weiter modifizieren und es letztlich zur Speicherung an den Index weitergeben.

text-analysis
Abb: Text Analyse

 

Die Textanalyse wird zum Einen, wie oben gezeigt, bei der Indexierung von Dokumenten angewendet, zum Anderen auch um die eingegenen Suchbegriffe zu analysieren.

Search Suggest

Neben der Facettierten Suche und der Volltextsuche zählt die Search-Suggest Funktionaltiät zu den häufig eingesetzten Suchmöglichkeiten in einem eCommerce System. Auch hier bietet Elasticsearch mit dem Completion Suggester Feature eine Standardlösung. Ein Nachteil dieser Lösung ist die Einschränkung, dass lediglich feste Terms angeboten werden, die während der Indizierung gespeichert wurden.

Die durch Contorion eingesetzte Webseite geht hier den Weg, alle Terms, die für die Search-Suggest angeboten werden sollen in einem Feld completion_terms zu indizieren und mit einem einfachen Analyzer, der lediglich Stopwörter entfernt, zu analysieren. Um im UI alle Produkte auszugeben, die dem eingegebenen Begriff entsprechen, wird ein Filter vom Typ edge_ngram angewendet. Dieser holt die Search Suggest Terms und zeigt die mit der höchsten Trefferanzahl an.

completion
Abb: Search Suggest

 Fazit zu Case-Study Contorion

Der Talk hat in kürzester Zeit Möglichkeiten zur Verbesserung der im eCommerce Bereich am häufigsten eingesetzten Suchfunktionalitäten aufgezeigt. Neben den oben beschriebenen Themen wurden auch Lösungen für Themen wie Data Driven Ranking und Personalization: Dynamic Pricing vorgestellt, die den Rahmen dieses Blogposts sprengen würden. Über die Github Pages des Talks können alle Themen nochmal im Detail nachgelesen werden.

Spryker commerce framework in a nutshell

Nach einen informativen Talk von Michael Geers (neuland bremen GmbH) zum Thema One JS Framework is not enough – Building a Single Page Shop with Multiple Teams, der einige gute Ideen hinsichtlich der Entwicklung moderner UX vorstellte, war als nächster Talk Spryker commerce framework in a nutshell von Fabian Wesner (CTO, Spryker Systems GmbH) auf der Agenda.

Prinzipien, Pattern + Best Practices

So setzt sich Spryker zum Ziel, durch ihr Framework die Produktivität der Entwickler entgegen dem Einsatz von Standardshopsystemen wie Magento zu optimieren und zu verbessern. Insbesondere werden hier Themen wie

  • Clean und SOLID Code
  • Konsistentes Software Design
  • Strikte Modularisierung
  • Generisches Featurset wie z. B. eine State-Machine (oder Rule-Engine)
  • Hohe Performance
  • Getesteter Code
  • Stringente Vermeidung von schlechten Best Practices anderer Systeme, wie ein Full-Page-Cache, Events oder AOP

durch Fabian Wesner ins Feld geführt. Die meisten der genannten Ansätze und Prinzipien tragen sicherlich zu einem schnell einsetzbaren und leicht erlernbaren Framework sowie zur guten Wartbarkeit bestehenden Codes bei. Der Einsatz von Spryker wird dadurch somit letztlich mit hoher Wahrscheinlichkeit zu einem erfolgreichen Projekt führen. Auch darüber, dass es von Vorteil ist, keinen FPC zu benötigt, um ein eCommerce System mit guter Performance online zu stellen gibt es wenig Diskussionsbedarf. Auch wenn man bei dieser besonders betonten Aussage erneut das Gefühl hatte, dess es sich wieder um einen versteckten Seitehieb Richtung Magento handelte.

Warum aber Events oder AOP zu schlechten Best Practices zählen sollen erschließt sich mir nicht komplett. Der Sinn eines Einsatzes dieser Technologien und der daraus resultierende Nutzen hängt sicherlich stark davon ab, wie Diese eingesetzt werden. Fest steht, dass ein Entwickler damit mächtige Werkzeuge in die Hand bekommt, sinnvoll und verantwortungsbewußt eingesetzt können gerade im Projektgeschäft Anforderungen elegant umgesetzt werden, die ansonsten entweder einen größeren Aufwand und damit mehr Kosten verursachen würden, oder den Entwickler zu einer weniger eleganten Lösung zwingen. Spryker will hier einen anderen Weg aufzeigen und verzichtet vollständig auf diese Möglichkeiten. Ob das Framework davon profitiert müssen die Entwickler selbst entscheiden.

Architektur

Aus der Vogelperspektive betrachtet handelt es sich bei Spryker um zwei eigenständige Anwendungen, nämlich Zed für das Backend und Yves für das Frontend. Hierbei hat Yves keinen direkten Zugriff auf die Datenbank, sondern holt sich die Daten entweder aus einem Key-Value Store System, hier Redis, oder einem Elasticsearch Index. Weiterhin greift Yves über eine proprietäre API, die einem ähnlich Ansatz wie RPC folgt, auf Zed zu und bedient sich an der dort bereitgestellten Funktionalität.

Spryker_Framework
Abb: Spryker Framework

Etwas seltsam hört sich die Aussage an, dass die Daten im Key-Value Store und dem Elastisearch Index per CRON über die API von Zed synchronisiert werden. Sprich hier könnten in großen Systemen, wenigstens in der Theorie, erhebliche Dateninkonsistenzen entstehen. Detailliert ging der Fabian Wesner jedoch nicht auf dieses Thema ein, was sicherlich noch einen intensiveren Blick hinter die Kulissen notwendig machen wird.

Performance und Skalierung

Die Aussage zum Thema Performance und Skalierung beschränkte sich hauptsächlich auf die Aussage, dass eine Software schnell by Design sein muss. Die kommunizierten Ladezeiten < 50 ms, auf Bare Metal sogar < 30 ms, hören sich auf jeden Fall vielversprechend an, insbesondere wenn diese ohne Caching erreicht werden. Aber auch hier kam wieder ein versteckter Seitenhieb in Richtung Magento, dass eben KEIN FPC benötigt wird.

Software Design

Eine der grundsätzlichen Entscheidungen von Fabian Wesner und somit auch von Spryker, ist ein klares Bekenntnis zu PHP als hauptächliche Implementierungssprache. Dieser Ansatz ist durchaus nachvollziehbar, da man durch Synergieeffekte aus, und den konsequenten Aufbau des Know-How in den einzelnenen Teams die Entwicklung sicherlich schneller vorantreiben kann. In vielen Sessions der Veranstaltung konnte man allerdings heraushören, dass mittlerweile gerade größere Firmen mit mehreren Teams hier den Schritt in eine andere Richtung, zu einem heterogenen Ansatz machen und ihren Teams bei der Auswahl der Tools und Programmiersprache freie Hand lassen. Was hier der richtige Ansatz ist wird sich erst in Zukunft zeigen. Vielleicht sind ja auch beide Ansätze der richtige Weg.

Die aktuell ca. 100 vorhandenen Bundles (es handelt sich nicht um Symfony Bundles) folgen hierbei strikt Prinzipien wie Single Responsibility und Separation of Concerns. Um diesen Prinzipien folge zu leisten zu können, stellt jedes Bundle hat eine eigene Facade zur Verfügung, über die ausschließlich mit anderen Bundles kommuniziert wird.

Horizontal ist das Framework klassisch in die vier Schichten

  • Presentation Layer
  • Communication Layer
  • Business Layer
  • Persistence Layer

unterteilt, vertikal wird eine fachliche Trennung vorgenommen. Auch hier fließt der Gedanke der Self-Contained-Systems mit ein. Inwieweit man diesen Gedanken tatsächlich bis zum Ende durchgezogen hat lässt sich aus der Präsentation nicht entnehmen.

Über Composer können Bundles installiert und deren Dependencies verwaltet werden. Hierbei wird strikt auf die Einhaltung von Semantic Versioning geachtet umd die Rückwärtskompatibilität gewährleisten zu können. Für mittlere und große Systeme dürfte dies sicherlich ein gewichtiger Pluspunkt sein, da die Erfahrungen aus der Vergangenheit, gerade mit Magento gezeigt haben, dass hier enorme Probleme und damit verbunden auch Kosten entstehen können.

Insgesamt verspricht sich Fabian Wesner durch das Software Design höhere Produktivität, gerade mit großen Teams. Zusätzlich kann so jedes Bundle der Applikation separat aktualisiert, erweitert und gelöscht werden.

Fazit zu Spryker

Grundsätzlich fühlt man sich bei dem von Fabian Wesner vorgestellten Framework irgendwie an die EJB 2 Architektur aus der Java Welt erinnert, was nicht zwingend schlecht sein muss! Dass Technolgien wie DI, AOP und Events nicht oder nur sehr rudimentär verwendet werden, hingegen stark auf Pattern wie Factory Klassen, Facade und Data Transfer Objects gesetzt wird, verstärkt den Eindruck noch zusätzlich. Kritisch betrachtet muss sich Spryker jedoch selbst hinterfragen, ob man sich mit dem gewählten Ansatz auf dem richtigen Weg, der ziemlich konträr zu den aktuell stark gehypten Mircoservices verläuft, befindet. Gefühlt wird sich ein Shopsystem, das auf Spryker setzt, stark in Richtung eines Monolithen (oder sogar zwei, mit Zed und Yves) entwickeln, auch wenn versucht wird, das kommunikativ geschickt zu umgehen.

Aus meiner Sicht bietet Spryker mit seinem Framework einen Anatz der durchaus seine Stärken hat, auch wenn Stefan Wesner als CTO nicht unbedingt den aktuellen Hypes hinterherläuft – was ich aus meiner Sicht positiv bewerte. So nehme ich Spryker, mit meinem derzeit noch oberflächlichen Verständnis, als ein solides Framework wahr, auf dessen Basis mittlere und große Projekte schnell, effizient und ohne großen Schnick-Schnack umgesetzt werden können. Ob es sich jedoch gegen Magento, Shopware & Co. behaupten oder Diese gar verdrängen kann, wie Fabian Wesner prophezeit, möchte ich bezweifeln. Ein Konkurrenz zu Systemen wie Websphere, Hypris oder Demandware sehe ich zum aktuellen Zeitpunkt in gar keinem Fall, ich denke hier ist der Abstand einfach zu riesig.

Was mir nicht gefällt, und das kam über die gesamte Veranstaltung immer wieder unterschwellig zum Vorschein, waren die ständigen Seitenhiebe aus dem Spryker Lager in Richtung Standard Shopsysteme, wobei hier gefühlt hauptsächlich Magento im Fokus stand. Aus meiner Sicht hat Spryker das aus den oben beschriebenen Gründen weder nötig, noch ist es aus meiner Sicht professionell. Sorry!

Zusammenfassung Code.Talks commerce special 2016

Die anschließenden Talks zu den Themen Sylius – Decoupled eCommerce Platform, MicroServices – Modularizing a Shop Platform und Mastering Technical Excellence in Large Scale Digitalization Projects am Case Fraport waren ebenfalls durchweg interessant und informativ.

Insgesamt hat das Code.Talks Team mit den commerce special 2016 einen rundum gelungenen Spin-Off hervorbringen können. Wie auch bei den Veranstaltungen in Hamburg, war die Location mit der Kulturbrauerei perfekt ausgewählt. So bieten zum Einen die Kinosäle, im Vergleich zu anderen Veranstaltungen, eine ausserordentlich passenden Umgebung um die Vorträge mitzuvervolgen. Zum Anderen war kulinarisch vom Frühstück, über das Mittagessen bis hin zu Snacks in Form von Popcorn und Softdrinks alles vorhanden um die Veranstaltung zu einem kleinen Erlebnis werden zu lassen, Hut ab!

Einziger Wehrmutstropfen aus meiner Sicht: Es hätten ein paar Steckdosen mehr sein können, um die leergelaufenen Laptops der vielen Entwickler wieder mit Strom zu versorgen 😉

Kommentar abgeben

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.