INSIGHTS ABOUT YOU limited deals: lessons learned

ABOUT YOU TECH

ABOUT YOU TECH

7 min read

Autor: Alexander Fedtke

Wenn man mich fragen würde, was der größte Unterschied zwischen der Kultur von ABOUT YOU und vielen anderen Unternehmen ist, dann würde mir als erstes die Geschwindigkeit einfallen, mit der Projekte angegangen und umgesetzt werden. Ende April war die Idee geboren, einen Private-Shopping-Club unter der Marke ABOUT YOU aufzubauen. Zu diesem Zeitpunkt gab es nicht mehr als diese wage Idee und den Plan, sie möglichst schnell zu realisieren. Innerhalb von zwei Monaten sollte die Plattform stehen und den Kunden von ABOUT YOU täglich neue Marken-Aktionen, Newsletter und eine eigene Mobile-Seite bieten.

In den ersten Wochen wurde das Konzept entwickelt und parallel die technische Umsetzung geplant. Und jetzt können wir sagen: Herzlich willkommen in der Familie, ABOUT YOU limited deals!

[caption id=”” align=”alignnone” width=”663"]

Marken-Aktionen bei ABOUT YOU limited deals[/caption]

Ein neues Projekt
Nachdem wir den straffen Zeitplan verdaut hatten, kam sehr schnell Begeisterung für diese neue Herausforderung im Team auf. Ein Projekt ohne Altlasten zu starten ist sicherlich der Traum jedes Entwicklers. Bei der Möglichkeit, die Technologien frei auszuwählen, besteht natürlich immer die Gefahr auf die falsche Alternative zu setzen. Mit den folgenden Anforderungen im Hinterkopf haben wir deshalb einige Technologien evaluiert:
- Wir möchten OpenSource-Projekte mit starker Community verwenden
- Die Projekte sollen etabliert und gut getestet sein
- Die Einarbeitungszeit soll für das gesamte Team so gering wie möglich sein
- Das Gesamtsetup soll modern und zukunftsfähig sein
- Das Know-How muss im Team & im Unternehmen bereits vorhanden sein
Da wir bereits kleinere Projekte erfolgreich mit AngularJS umgesetzt hatten, lag es nahe dies auch für ABOUT YOU limited deals (AYLD) in Betracht zu ziehen. Daran hing allerdings eine weitaus schwerwiegendere Frage, nämlich ob es sinnvoll ist, eine ganze Webseite vollständig als API-basiertes-Projekt umzusetzen. Auch Browserkompatibilität, Funktionsfähigkeit im Falle von JavaScript-Fehlern und Memory-Leaks bei langen Sitzungen waren Punkte, die später nicht für Probleme sorgen durften.

Frontend-Setup
Das Setup mit AngularJS konnte uns insofern überzeugen, als dass eine Unterstützung bei IE9 für uns ausreichend war. Desweiteren sind Unit- und Funktionstests mit Karma und Protractor in AngularJS leicht umsetzbar, so dass sich auch die Risiken bezüglich des weitreichenden JavaScript-Einsatzes gut steuern lassen.
Auch die Suchmaschinenoptimierung musste später gut implementierbar sein. Evaluiert und mittlerweile im Einsatz haben wir dafür die nodeJS-Lösung prerender.io. Bei Crawleraufrufen wird die Webseite durch prerender.io statisch gerendert und ausgeliefert.
Wer schonmal ein vollständiges Frontend-Buildsystem mit npm, bower, und gulp aufgesetzt hat, der weiß, dass in dieses Setup praktisch beliebig viel Zeit fließen kann. Wir haben uns deshalb entschieden, den fertigen Yeoman-Generator gulp-angular zu nutzen. Dieser bietet viele Optionen und ermöglicht ein professionelles Projektsetup innerhalb von wenigen Minuten.
Durch verschiedene gulp-Commands lassen sich dann unmittelbar
- Unit-Tests ausführen
- Funktionstests durchführen
- Live- und Developmentumgebung builden
- Watch-Tasks ausführen
- Ein Webserver inklusive BrowserSync starten

REST-API in PHP
Der Vorteil einer REST-API-basierten Lösung wird für mich dadurch deutlich, dass erstaunlich wenig Logik in der API notwenig ist. Die meisten Anfragen sind einfache GET-Requests, die einfache Datenobjekte aus einer Datenbank abholen, damit diese im Frontend angezeigt werden können. Die meisten PHP-Frameworks wurden allerdings mit dem Anspruch konzipiert, vollständige Webseiten als HTML auszuliefern. Dies geht teilweilse mit langen Ladezeiten durch große PHP-Libraries einher sowie der Notwendigkeit, nachträglich viel Caching zu verwenden.
Das auf zend framework 2 basierende Tool Apigility gewinnt daher zusehends an Nutzern, da es die Erstellung von REST-APIs mit sehr wenig Overhead und auf Basis bewährter Technologien bietet. ZF2 ist stark modular aufgebaut und ermöglicht, dass nur die für eine REST-API benötigten Komponenten geladen werden, wodurch die Bootstrapping-Zeiten sehr niedrig bleiben (ein Test auf einer lokalen virtuellen Maschine ergab unter 50ms, mit HHVM unter 20ms).
Die Notwendigkeit für geringe Antwortzeiten ergibt sich daraus, dass vom Frontend mehr Requests als in einer klassischen Webanwendung an die API geschickt werden. Umso wichtiger ist es, die Antwort-Zeiten und damit die Last klein zu halten. Aus diesem Grund haben wir auf den Einsatz von großen monolitischen Libraries und ORMs verzichtet und dort, wo es problemlos möglich war, Plain-PHP bzw. PHP-Extensions verwendet. Die einfache Natur der notwendigen Logik innerhalb der API hat dies enorm begünstigt.
Der größte Vorteil bei der Verwendung von Apigility ist allerdings nicht die Geschwindigkeit, sondern das extrem einfache Setup und die leichte Konfigurierbarkeit. Apigility ist prinzipiell nicht viel mehr als eine gelungene GUI zum Konfigurieren und Dokumentieren von ZF2-REST-APIs. Das Ergebnis ist aber nicht unlesbarer generierter Code, sondern leere Boilerplate-Klassen und eine ZF2-Modulkonfiguration, aus der sich Apigility auch bei nachträglichen Änderungen seine Daten zieht. Das Standard-Setup von Apigility erstellt zudem ein sauberes nahezu leeres Projekt mit Composer, wodurch man sofort anfangen kann seine eigene API zu entwickeln.

Architektur
Durch den geringen Overhead beim Setup einzelner Projekte macht es für uns am meisten Sinn, die einzelnen Teile der Plattform möglichst in einzelne Repositories auszulagern und als eigenständige Code-Projekte zu behandeln. Dies ermöglicht separate Releases und eine saubere Separation of Concerns.
Datenseitig ist das Persistenz-Modul zentral (siehe Abb. unten), welches die Datenbankabstraktionsschicht und jegliche damit zusammenhängende Funktionalität enthält. Alle weiteren PHP-Projekte binden dieses Modul ein und bestehen ansonsten aus kaum mehr als einer Schnittstellenbeschreibung (Public- und Backend-API) bzw. Funktionsaufrufen (Cronjobs).

[caption id=”” align=”alignnone” width=”607"]

Modulare API-basierte Architektur[/caption]

Vier Wochen Zeit
Ein Projekt auf der grünen Wiese zu starten hat zwar unbestreitbar Vorteile, aber ohne den Fokus auf das Wesentliche können Konzepte und Featurewünsche leicht ausarten. Für uns galt daher ganz klar, dass das Ziel ein Minumum Viable Product (MVP) ist, also eine für den Kunden ansprechende Shopping-Plattform, die auf die Kern-USPs reduziert ist.
Daraus folgt unmittelbar, dass auch bei den Konzepten viel technischer Input notwendig ist, damit die Erstkonzept nicht mit technisch aufwändigen Nice-to-haves zu einer unendlichen Geschichte wird.
Daher ist es immer wieder notwendig, die gewünschten Features und Designs zu hinterfragen. Nur in enger Abstimmung mit Konzeptern und durch kurze Entscheidungswege lässt sich so arbeiten. Ein Kontaktformular? Ist das wirklich jetzt schon notwendig? Reicht es nicht, wenn wir eine hilfreiche Seite mit Kontaktinfos haben? Die Entscheidung wird unmittelbar gefällt: Ja, es reicht vorerst. Mehrere Stunden Entwicklungs- und Testingzeit können wir auf wichtigere Features verwenden.

Lessons learned
Aus technischer Sicht ist das Projekt bislang ein voller Erfolg, von dem wir einzelne Ansätze sogar schon auf andere Projekte übertragen haben. Die APIs und auch das Frontend sind ohne dedizierte Performance-Verbesserungen bereits sehr performant und bieten ohne Caching eine flüssige User-Experience. Mit zusätzlichen Caching-Mechanismen plus Cache-Prewarming wären die Ladezeiten praktisch nicht mehr zu bemerken. Durch den konsequent REST-API-basierten Ansatz können die API-GET-Requests fast vollständig gecached werden.
Die Architektur und die verwendeten Technologien haben bislang all unsere Erwartungen übertroffen und scheinen auch sehr gut dafür geeignet zu sein, um ein deutliches Wachstum der Plattform zu überstehen. Das lässt sich zum einen daran erkennen, dass bislang alle Featurewünsche ohne umständliche Workarounds möglich waren und wir zum anderen wir bis zu sechs Entwicklern gleichzeitig an dem Projekt arbeiten konnten, ohne durch (Merge-)Konflikte in unserem Arbeitsfluss behindert zu werden.
Die klare Trennung zwischen Frontend und Backend in Verbindung mit Standardtechnologien ermöglicht uns weiterhin, dass wir neue Entwickler oder Freelancer schnell produktiv einbinden können.
Die konsequente Anwendung des MVP-Ansatzes hat es uns ermöglicht, AYLD innerhalb des straffen Zeitplans an den Start zu bringen und dabei unsere Ressourcen am effektivsten zu nutzen. Dafür mussten wir lernen zu akzeptieren, dass nicht alles immer 100%ig sein kann und auch, dass viele Konzepte wieder überdacht werden müssen. Vieles kann sich dabei auch nur iterativ ergeben, weil es niemals das perfekte Konzept gibt.
Aus Entwicklersicht ist es dabei trotzdem enorm wichtig, dass die Tasks, die umgesetzt werden sollen, in dem Moment final sind und nicht während der Entwicklung geändert werden. Wir haben so gut wie möglich versucht während der gesamten Umsetzung unseren Scrum-Prozess einzuhalten und die Anforderungen nicht während des Sprints abzuändern. Und falls das mal nicht möglich war, dann zumindesten nicht während der Umsetzung. Dies war teilweise kräftezehrend, hat sich aber unter dem Strich bewährt, weil wir dadurch sichergestellt haben, dass alle Entwickler konzentriert an ihren Aufgaben arbeiten konnten und alle Anforderungen einen klar definierten Rahmen behielten. Dass das Aussehen des Buttons dann erst in zwei Wochen angepasst wurde, daran haben sich schnell alle Beteiligten gewöhnt.
Im Nachhinein scheint der Zeitplan gar nicht mehr so straff, wie es anfänglich den Eindruck machte. Wir konnten einige Meilensteine früher als geplant erreichen und weitere hebelnde Features wie das Freunde-werben-Freunde-Programm zusätzlich umsetzen. Der Grund dafür liegt wahrscheinlich im Zusammenwirken eines guten Teams, dem gelebten MVP-Gedanken und der richtigen Technologieauswahl. In diesem Sinne, herzlich willkommen ABOUT YOU limited deals!

Und sonst? Open Source!
Wir haben für ABOUT YOU limited deals auf fantastische Technologien zurückgreifen können, die uns frei als Open Source zur Verfügung standen. Daher möchten wir einige unserer Libraries, die jetzt auch für AYLD zum Einsatz kamen, gerne der Community als Open Source zur Verfügung stellen. Mehr Infos dazu gibt’s in den nächsten Wochen auf dem Blog.

Weiterführende Links
ABOUT YOU limited deals
Apigility
Yeoman generator for AngularJS with GulpJS
AngularJS mit EcmaScript 6
prerender.io

More articles

ABOUT being fast: Unsere Tech Team-Strukturen & -Prozesse
ABOUT YOU TECH

ABOUT YOU TECH

4 min read