The First Shop - 100%

 
 
First-Shop.jpg
 

Cloud Engineerwas bisher geschah..

Nachdem wir natürlich den erfolgreichen Launch unseres neuen ReactJS Frontends (Poseidon) im Herbst 2018 gehörig feierten, folgte im Anschluss die Konzeption des „First Shop“. Wie an den kürzlich stattgefundenen Expansionen der XXXLutz Gruppe leicht erkennbar ist, machen unsere Eigentümer keine halben Sachen! Parallel zum Ausrollen einer weiteren Warendemo in Serbien im Mai 2019 sollen so schnell wie möglich alle echten Onlineshops ebenfalls von Poseidon profitieren. Daher ging es für unsere Stakeholder und PMs direkt wieder ans Reißbrett. Sie mussten die wichtigsten Features der alten Frontends identifizieren, ohne denen wir keinen Onlineshop releasen könnten.

Und vor Allem: welcher der verbleibenden 18 Onlineshops sollte es werden? Die Entscheidung fiel uns schwer, war am Ende des Tages aber auch wiederum klar nachvollziehbar: der österreichische Onlineshop! Schließlich befindet sich hier unser Herz, unsere Firmenzentrale.

Bis es dann soweit war, konnten wir Web Developer uns jedoch nicht auf die faule Haut legen (das widerspricht ohnehin unserer Natur). Technische Schuld baut sich in jedem noch so detailliert geplanten System auf. Und auch wir mussten uns somit ans erste Refactoring machen.

Refactoring

Wir hatten uns 2018 bei der API noch nicht getraut, auf GraphQL zu setzen, da die Bibliothek noch in der 0.x Phase war. Stattdessen einigten wir uns damals auf den etablierten JSON API Standard. Die OpenSource Community hat jedoch wieder einmal bewiesen, wie schnell sich das Web mit vereinten Kräften weiterentwickeln kann. So: GraphQL it is!

Das Refactoring machte aber hier nicht halt:

Weiterentwicklung

Parallel zu den oben genannten Hürden mussten wir immer wieder weitere Developer mit unserem neuen Stack vertraut machen. Wir eröffneten sogar einen neuen Dev-Standort in Barcelona, was eine Revolution unserer gesamten internen Kommunikation notwendig machte.

Um das zu bewerkstelligen, etablierten wir einen wichtigen Baustein unseres aktuellen Wertesystems: wir leben täglich eine Kultur der Weiterbildung. Davon auszugehen, dass jede/r Kollege/in alles weiß, ist keine Option. Etwas nicht zu wissen, ist kein Kündigungsgrund. Wir müssen angstfrei Fragen stellen dürfen, um uns gesund weiterentwickeln zu können. Jeder Fehler, den wir machen, bringt uns voran. In unseren PRs pflegen wir daher strikt einen inklusiven und edukativen Ansatz. Jede/r Dev ist dazu eingeladen, für Kollegen/innen kurze Workshops bzw. Trainings zu machen. Um standortübergreifend Wissen auszutauschen veranstalten wir zweiwöchentliche interne Meetups, in denen die neuesten Techniken oder am Meisten gewünschten Tutorials vorgestellt werden.

Performance

Bei 1400 zu rendernden Menüpunkten und knapp 5500 DOM Nodes zählt jede noch so kleine Unachtsamkeit aufs Performance Konto ein. Natürlich ist das ein Thema von vielen, die jedem von Anfang an bewusst sein müssen, aber oft holen einen die Betriebsblindheit und strukturelle Probleme ein. Vergangenen September, kurz vor unserer eigens gesetzten Deadline, wurde uns klar, dass wir ohne ein überarbeitetes Performance-Konzept nicht online gehen können. Da wir auf die Schnelle kein eigenes Team auf die Probleme ansetzen konnten und eine unvoreingenommene Außensicht oftmals hilfreich ist, haben wir um Unterstützung von externen, internationalen Experten gebeten.

Schlechte Performance wirkt sich generell auf alle Bereiche aus. Wenn Kunden einen schnellen Computer und moderne Endgeräte als Voraussetzung für einen Besuch bei uns benötigen würden, fiele der Umsatz drastisch. Der Impact ist jedoch auch für uns Entwickler massiv zu spüren: Je mehr Zeit der Shop zum vollständigen Laden benötigt, desto länger benötigen auch die GUI-Tests, die für jeden Entwickler dadurch zur Bremse wird. Auch unser SSR-Service benötigt massiv mehr Ressourcen und verursacht höhere Kosten. Alles in Allem zahlt sich diese Investition am Ende des Tages wirklich unglaublich aus!

Die Performance Probleme gehören mittlerweile der Vergangenheit an. Wie so oft fehlte uns auch ein wenig Sensibilität, die wir jedoch ab sofort in unseren Workflow integrieren. Eine Konsequenz daraus ist zum Beispiel die Planung zur Integration von Lighthouse CLI. Sobald ein neuer Branch unter einen definierten Schwellenwert fällt, wird ein Deployment dieses Features verhindert, bis die Performance entsprechend reviewed und optimiert wurde.

Live

Zum Zeitpunkt der Erstellung dieses Blog Posts landen 50% des österreichischen Traffics bereits auf Poseidon. Da sich laut unserem User-Tracking das Verhalten unserer Kunden zum Positiven hin verändert hat, gehen wir davon aus, alles richtig gemacht zu haben. Täglich wird daher der prozentuelle Traffic auf die neue Seite erhöht, damit wir so schnell wie möglich 100% erreichen. Auch die Architektur hält den Erwartungen stand und skaliert in der Cloud wie erwartet. Das Weihnachtsgeschäft kann kommen!

Begleite uns

Es gibt vielfältige Bereiche, in der wir deine Unterstützung, dein Know-How und Mindset benötigen. Wir wollen weiter wachsen. Aktuell suchen wir Entwickler, Product Owner und Cloud Engineer die uns bei der Reise in die Zukunft zur Seite stehen wollen.

Author: Michael Huber, Teamlead E-com Development

*English version to be found here

projectsxxxldigital