Ende letzten Jahr begegnete uns die Storefront „Lizards & Pumpkins“. Nur ein weiteres Katalog-Frontend? Um dem auf den Grund zu gehen haben wir gerne das Angebot der Gründer angenommen, das Frontend in einem Workshop auszuprobieren.

Vergangenen Mittwoch und Donnerstag trafen wir uns daher im Büro der Fatchip GmbH, die uns ihren Meetingraum zur Verfügung stellte. Gemeinsam mit den Entwicklern Vinai, Fabian und Tim haben wir erste Schritte gemacht und sind – so viel sei hier schon verraten – erstaunlich weit gekommen.

Was ist Lizards & Pumpkins

Lizards & Pumpkins folgt der aktuell sehr populären Denkweise, den Shop in eine Applikation mit der Logik (für Checkout und andere Berechnungen) und ein zweite Applikation für das schnelle Rendern des Katalogs zu trennen. Dieser Ansatz begegnet einem bei Sprkyer, ONGR, Commercetools und einigen anderen.

Lizards & Pumpkins stellt dabei nur den schnellen Katalog bereit, also das rendern von Startseite, Listenansichten (Kategorien und Landingpages) und Produktdetailseiten. Diese Applikation wird vor das bestehende Shopsystem gesetzt. Der Ansatz ist aus von ONGR her gut bekannt und wie auch dort kann hier ein stufenweiser, risikoloser Wechsel in die neue Applikation erfolgen.

Die Technik hinter der Storefront

PHP7 + KeyValue-Store
mehr braucht es nicht.

Die Storefront macht dabei äußerst wenig Vorgaben und kommt extrem schlank daher. PHP7 ohne Framework und ein KeyValue-Store stellen die Basis für die neue Applikation. Außer einem Webserver und PHP7 wird für die ersten Schritte nichts benötigt. Als KeyValue-Store stehen Filesystem-Adapter bereit, die es jederzeit erlauben, auch ohne tiefes Verständnis in die Daten zu schauen. Des weiteren gibt es auf GitHub bereits Adapter für Redis und memcached.

Die Idee: Mit wenigen Vorgaben und einfacher Austauschbarkeit ist das System für jeden erfahrenen Entwickler zu verstehen und an die eigenen Wünsche anpassbar. Dadruch werden Flamewars über Frameworks und Technologien geschickt umgangen.

Gewöhnungsbedürftig und diskutierbar ist die Tatsache, dass weite Teile des Renderings clientseitig per JavaScript umgesetzt sind. Das lässt sich natürlich jederzeit im Projekt ändern, als Backendler braucht man aber einen Moment für den Switch.

Der Importer beasiert per default auf XML-Dokumenten, die mittels Workern aufbereitet und in den KV-Store geschrieben werden. Dank einer Queue-Implementierung kann dieser Prozess beliebig horizontal skaliert werden, so dass Änderungen im Live-Projekt teilweise im Shop zu sehen sind, bevor das Backend nach dem Speichern neu gerendert hat. Die XML-Struktur zeigt deutlich den Magento-Hintergrund der Entwickler. Ich werte das jedoch weniger als Nachteil denn als gesunden Pragmatismus der einem auffallend angenehm an vielen Stellen im Projekt begegnet.

Lizenz und Geschäftsmodell

Ursprünglich entwickelt wurde das System für den Shop von 21run.com, der bis dato rein auf Magento lief. Die drei Entwickler hatten die Aufgabe, den Shop schneller zu machen ohne dabei das Backend auszutauschen.

Seitdem das Projekt erfolgreich an den Start ging, entwickeln Sie das Konzept konsequent weiter und unterstützen Entwicklungsteams beim Aufbau neuer Projekte.

Die Software selber ist unter der OpenSource-Lizenz BSD-3-Clause veröffentlicht.

Zwei Tage Powerworkshop

Wir hatten also nun zwei Tage die Chance, direkt mit Vinai Kopp, Fabian Blechschmidt und Tim Bezhashvyly erste Gehversuche zu unternehmen. Wie immer versuchen wir hier schnell Praxisbezug zu bekommen und mit echten Daten zu arbeiten. Nach einem halben Tag theoretischer Einführung teilten wir uns in drei Hands-On-Teams.

Lizards & Pumpkins Workshop

Import von Plentymarkets-Daten

Unser Kunde outlet46.de betreibt seinen Shop auf dem Plentymarkets System. Die Antwortzeiten sind dort leider den Anforderungen nicht gewachsen und unterliegen großen Schwankungen. Als Hotfix umgehen wir dies im Moment mit einem Fullpage-Caching im vorgeschalteten Loadbalancer – mit allen Nachteilen die Caching nunmal mit sich bringt.

Die Kollegen dort haben uns dankenswerter weise einen Export mit Artikeln und Kategorien des Shops bereit gestellt. Nachdem diese in das XML-Schema gebracht wurden, konnten wir einen ersten Import laufen lassen:

30 Sekunden für 5.000 Artikel bei einem einfachen, nicht ausglasteten Worker und Filesystem-Backend – das kann sich auf jeden Fall sehen lassen. Damit hatten wir echte Artikeldaten für erste Tests.

Templating

Das Demopackage liefert ein hübsches Basistemplate für das Frontend als auch für Magento für den Checkout-Teil des Shops mit.

Ebenfalls nach Vorlage des oben genannten Kunden haben wir das Template für Kategorie und Produktdetailseite angepasst. Der backendseitige Teil passiert in einfachen .phtml-Dateien. Ein Großteil der Seite wird jedoch als einfaches JSON ausgeliefert und dann mittels JavaScript gerendert. Hier kommt RequireJS als DependencyManagement zum Einsatz. Wie bereits erwähnt ist dieser Teil gewöhnungsbedürftig und aus SEO-Sicht sicher zu diskutieren. Das lässt sich jedoch auch ändern und im Projekt anders handhaben. Aus Performancesicht ist mit dem Default das beste Ergebnis für den Kunden zu erzielen.

Schön ist, das bereits die standardmäßig erwarteten Funktionen wie Filter für die Aftersearch-Navigation, Autosuggestion, Variantenauswahl und so weiter zur Verfügung stehen und einfach angepasst werden können.

OXID Connector

Die dritte Gruppe hat sich um die Entwicklung eines Connectors zu OXID eShop, eines der bei uns am häufigsten eingesetzte Shopsystem, gekümmert. Das kleine Modul erlaubt es, einen Artikel von den Seiten die mit Lizards & Pumpkins gerendert werden in den Warenkorb zu legen sowie die Userdaten auszulesen. Wie bei ONGR kommt dabei ein einfacher Cookie zum Einsatz.

In einem zweiten Schritt haben wir dann einen Export der Artikeldaten in das vorgegebene XML-Schema umgesetzt, so dass ein default OXID bereits an die neue Storefront angeschlossen werden kann.

Performance von Lizard & Pumpkins

Die Zahlen sehen gut aus! Auf einem Standard-Setup mit Filebackend und ohne Optimierung rendert eine Kategorieseite in etwa 100ms (ttfb) sowie die Produktdetailseite in 50ms (ttfb). Mit Umstellung auf Redis oder memcached sowie einigen Optimierungen am Setup, lassen sich mit Sicherheit beide Seitentypen in den 2-stelligen Millisekundenbereich drücken. Wichtig ist, dass man auch das JavaScript im Auge behält und nicht die Performance durch rasend schnelle Time To First Byte im Browser verbummelt.

Fazit

In nur 2 Tagen Einführungsworkshop haben wir mit den drei Entwicklern:

  • einen Import aus Plentymarkes / CSV-Daten entwickelt
  • ein erstes Template angefangen, das dem Look & Feel des bestehenden Shops nahe kommt
  • einen Connector zu OXID gebaut
Unser Tipp:
Noch heute die perfekt vorbereitete DevVM hochfahren, Kaffee schnappen und ausprobieren!

Die drei Profis haben uns die wichtigsten Punkte vorgestellt und uns Hands-On weiter gebracht als wir uns das vorher vorgestellt haben. Durch die Bank weg bleibt der Eindruck: Der Verzicht auf viele Technologien macht das Projekt schnell und erlernbar für jeden Entwickler. Die geradlinige Architektur sieht vor bei Bedarf einzelne Komponenten austauschen zu können und an den Bedarf des Projekts anzupassen.

Wer über den Wechsel der Storefront nachdenkt sollte sich definitv diese Storefront anschauen oder besser noch vorstellen lassen.