Ein eCommerce Frontend mit React.js in zwei Monaten – Ein Praxisbericht

Wer die aktuelle Diskussion um das Buzzword headless verfolgt, der findet es in fast in jedem Kontext – egal ob es um CMS oder Shopsysteme geht. Es scheint das neue Allheilmittel für die moderne Zeit und eine Konsequenz aus dem Microservice-Hype. Das hier von piazza blu realisierte Projekt bietet einen praxisbezogenen Blickwinkel in Bezug auf die Nutzen eines solchen Ansatzes. 

Die Ausgangssituation

Der Projektkunde agiert als reines Distanzhandelsunternehmen mit umsatzstarkem B2B-Schwerpunkt und kleinerem, aber auch relevantem B2C-Anteil. Die Vertriebsstrategie verteilt sich über mehrere Vertriebsmarken mit verschiedenen Sortimentsschwerpunkten in mehreren Ländern und Sprachen. 

Die Webseiten (Shop + CMS) wurden für B2B und B2C zeitlich versetzt auf verschiedenen Systemen aufgesetzt. Für Content hat der Kunde jeweils die internen Möglichkeiten der Shopsysteme genutzt und ergänzend WordPress eingesetzt. Zentral betrieben werden das ERP und das PIM. Diese Vorgehensweise scheint ein guter Kompromiss.

Das B2B-Geschäft mit viel Umsatz ist frei von den „Risiken“ der Änderungen und für den kleineren B2C-Anteil kann man etwas experimentierfreudiger sein. Es bedarf keiner Anforderungskonsolidierung für alle fachlichen Nutzer der verschiedenen Online-Kanäle. Umgekehrt gibt es aber auch das Problem, dass eine Synergie über die Kanäle nicht genutzt werden kann. Dies liegt daran, dass hier entsprechende Silos im Bezug auf Funktion und Daten bestehen. 

Die mittlerweile hohe Anzahl der eingesetzten Systeme bringt neben den Vorteilen (fertige Features für eine bestimmte Funktion, „Out-of-the-Box Speed“) auch die Herausforderung der Verwaltung und Integration dieser Systeme untereinander mit sich. Diese wirkt „belastend“, indem die durch fertige Features und deren Nutzung gewonnene Zeit wieder verbraucht wird – für das systemspezifische Management, die Integration und das dauerhafte Betreiben vieler Systeme.

Hier entsteht langfristig betrachtet ganz klar die These: Durch das Reduzieren der Systeme/Instanzanzahl kann man Zeit und Kosten sparen. Die Investition in Konsolidierung der Systemanzahl und Nutzung einer gemeinsamen, parametrisierbaren Schablone trägt langfristiges Potential in sich. 

Der jetzige Online-Redaktionsprozess (= jegliche Konzeption, Erstellung und Pflege von Inhalten) ist stark belastet vom systemspezifischen „Einbauen“ der Inhalte in das jeweilige System und bedarf in vielen Fällen der technischen Unterstützung für das jeweilige System. Durch Einsatz eines zentralen CMS und Vereinheitlichung und „Schablonierung & Strukturierung“ kann die Effizienz gesteigert werden, die „qualitativ“ (bessere Inhalte) oder quantitiv (mehr Inhalte) reinvestiert werden kann. 

Probleme im Überblick

• Die historisch gewachsene Struktur führt in Summe der Einzelsysteme zu hohen Kosten 
• Das managen der Integrationspunkte zu den mehrfach Shopsystemen wird zu aufwändig
• Frontend-Silos mit einer steigenden Anzahl von Templatesystemen und Frameworkversionen 
• Redaktionsprozesse werden durch das Verwalten in verschiedenen Systemen erschwert und verlangsamt

Die Zielsetzung

• Konsolidierung 
• Steigerung der Gesamteffizienz 
• Schnellere Redaktionsprozesse, Vereinfachung des Content Managements 
• Investitionsschutz und Nutzung der bestehenden Backendprozesse und Systeme
• Nutzung der technischen Vorteile PWA-basierter Architekturen
• Erstellung eines Styling-Frameworks zu einer sehr parametergesteuerten Umsetzung der Brandings von Vertriebsmarken
• Konsolidierung der funktionalen Basis und unnötigen Unterschieden
• Weniger systemspezifisches Management  
• Mehr Flexibilität 
• Bessere, lückenlose Integration von Inhalten zwischen CMS & Shopsoftware
• Gute Templates (systemübergreifend) 
• Filialübergreifende, systemübergreifende Synergie (Content, Shop)
• Kosteneffizienz im UX/Style-Development (Template, CSS)
• Effizienzsteigerung im Content-Prozess (Output steigern)
• Konsolidierung der Systemlandschaft (weniger Instanzen, weniger Kosten)

Die Architekturstrategie

Zunächst gilt es festzuhalten, dass die bestehende Systemlandschaft im Backend (PIM, ERP) komplett stabil bleibt. Im Bezug auf die Shopsysteme wird auf ein System konsolidiert, dass bereits mandantenfähig in die Landschaft integriert ist und die historisch gewachsene CMS-Landschaft wird ebenfalls auf ein System konsolidiert.

Beim Frontend fällt die Wahl auf React, aber kombiniert mit next.js für Server-Side Rendering auf Basis von node. Als Eintritt in die Backend-Services dient ein Graph QL fähiges API Gateway auf Basis von quarkus.io, das als Single Point of Contact für die Frontend-Anwendung dient und auch die Security konsistent nach außen über JWT Token abbildet.

• Ein zentrales headless CMS
• Headless Frontend auf Basis von React.js /next.js / node
• API Gateway auf Basis von quarcus.io
• Security via JWT Token
• Keine Changes in Prozessen / Backend
• Komplett paralleler Betrieb des neuen Frontends ist möglich

Die Umsetzung

Um das zeitlich eng gesteckte Ziel von 8 Wochen zu erreichen, bedarf es eines sehr klaren Scopes bis zum Livegang. Ein solches Vorhaben ist aufgrund der Risiken und Kompromisse, die nötig sind, nicht sinnvoll bei einem trafficstarken Shop. Also wählen wir einen Markenshop für eine neue Kundengruppe. Wir raten grundsätzlich zur Vorsicht bei Versprechungen über sehr kurze Durchführungszeiträume bei Shopprojekten, die ja in Coronazeiten von allen in den Mund genommen werden. Sie sind möglich, aber das Dreieck aus Zeit, Qualität und Kosten lässt sich auch in diesen Zeiten nicht außer Kraft setzen.

Im Sinne einer Priorisierung erfolgt also eine klare Diskussion im Team, welche Themen klar einem Post-Go-Live Scope zuzuordnen sind, also nicht für den Go-Live absolut notwendig sind. Weiterhin versuchen wir immer, das Projekt selbst von allen „Ramp-up“ Themen zu befreien. Welche Frameworks nutzen wir für’s Styling? Wie ist die Codestruktur? Wie machen wir die Buildpipeline? Welche Systeme muss man aufsetzen? Wenn diese Dinge nicht zum Start schon funktionieren, wird die Projektzeit deutlich belastet. Dies sind aber Prozesse und Fragen, bei denen man sich einer standardisierten Schablone bedienen kann. 

• Zum Start steht ein durch piazza blu zusammengestelltes Boilerplate-Template zur Verfügung, in dem alle Frameworks und Grundbestandteile bereits enthalten sind
• Das Entwicklungsteam arbeitete Corona bedingt komplett verteilt
• Das Projekt wurde in 8 Sprints je einer Woche durchgeführt
• Unkritischer, aber echter Shop als Go-live Kandidat

Das Ergebnis und der Added Value von piazza blu als Umsetzungspartner

Wir haben den Go-Live Termin und einen erfolgreichen Launch erreicht. Die Arbeitsergebnisse dieser ersten Phase kann man nun für die Konsolidierung der Shop-Frontends auf diese Plattform nutzen. Das zentrale headless CMS steht zur Verfügung und erlaubt die Pflege aller Inhalte. Eine Systematik zur Pflege der Seiten, derer Layouts und Grids wurde etabliert. Dadurch ist insbesondere eine komplexere Contentausspielung pflegbar (nach Segmentierung, Preislisten oder Anmeldestatus). 

• Wir verfügen über ein sehr gutes Erfahrungswissen mit SPA/PWA Frameworks und deren Integration (React, vue.js, Angular)
• Wir können auf erprobte und evaluierte Schablonen und Boilerplates zurückgreifen und ein Projekt kann direkt mit den wichtigen Dingen „starten“
• Continous Integration & Deployment können wir sehr weit vorbereitet zur Verfügung stellen
• Ein Hosting kann sehr schnell in jeglicher kubernetes-fähigen Public oder Private Cloud erfolgen
• Wir nutzen Agiles Vorgehen und SCRUM-Prozesse sehr zielgerichtet, um schnell und iterativ Ergebnisse zu erzielen

 

Mehr Infos zum Thema Headless:

piazzablu.com/headless