Shopware Frontends – Der Weg für Shopware 6?
Serhii KorzhLesezeit: 6 Minuten
Bei der Wahl einer E-Commerce-Plattform achten viele genau auf das Erscheinungsbild des Storefronts. Doch noch wichtiger ist die Flexibilität der Plattform bei der Anpassung von Design und clientseitiger Funktionalität. Geht es um den “sane defaults” Storefront, ist Shopware 6 schwer zu schlagen. Das Anpassen von Seiten mit Twig-Templates ist intuitiv und vielen PHP-Entwicklern vertraut. Es gibt jedoch einen weiteren Ansatz: Shopware Frontends.
Shopware Frontends, ermöglicht durch Shopwares umfangreiche Headless API, ist eine Sammlung von Vue.js-Paketen. Sie bieten CMS-Komponenten, API-Client, Composables (wiederverwendbare Blöcke von Geschäftslogik), API-Typenschema für TypeScript-Unterstützung und Hilfsmittel für Nuxt-Projekte. Damit lassen sich Twig-Templates aufgeben und ein hochgradig anpassbarer, interaktiver Storefront mit moderner Tooling erstellen, die Frontend-Entwicklern vertraut ist.
Wie alles hat auch Shopware Frontends Vor- und Nachteile. Warum sollte man es dem Standard-Storefront für Shopware 6 vorziehen? Lassen Sie uns das analysieren.
Was bietet Shopware Frontends?
Shopware Frontends ist keine einzelne Lösung, sondern eine Reihe zusammenarbeitender NPM-Pakete, Shopware API-Client, Vue 3 Composables, CMS-Komponenten, Nuxt 3-Modul, Hilfstools and API-Typen-Generator.
Diese Pakete lassen sich in verschiedenen Kontexten nutzen: Als eigenständiger Nuxt-Storefront, als Vue-App eingebettet in einen Standard-Shopware-Storefront oder innerhalb eines Astro-Projekts. Wir konzentrieren uns hier auf die Verwendung zum Aufbau einer Nuxt 3-Anwendung.
Komponenten
Wir sind zufrieden mit der Qualität der von Shopware bereitgestellten CMS-Komponenten. Sie lassen sich einfach einer Seite hinzufügen, das Typensystem hilft die richtigen Daten zu übergeben. Die CMSPage-Komponente ermöglicht es, die Verwaltung der Seiteninhalte an Shopware Experiences im Admin-Panel zu delegieren.
CMS-Komponenten zu überschreiben ist einfach - solange Ein- und Ausgangstypen (Props und Events) nicht geändert werden, kann kaum etwas schiefgehen. Zu beachten ist, dass dieselbe CMS-Komponente auf mehreren Seiten und in anderen CMS-Komponenten verwendet werden kann. Zusätzliche Props können übergeben werden, um zwischen diesen Anwendungsfällen zu unterscheiden.
Composables
Composables erleichtern den Aufbau eines benutzerdefinierten Storefronts mit Shopware Frontends enorm. Sie ermöglichen es Frontend-Entwicklern, die Kernlogik des Shops schnell zu implementieren, indem sie gebrauchsfertige Methoden und Datenrepräsentationen bereitstellen, die die API-Interaktion verdeckt abwickeln.
Möchte man beispielsweise Daten aus dem Warenkorb anzeigen oder dessen Inhalt ändern, ruft man einfach das useCart-Composable auf. Es stellt reaktive Eigenschaften wie cartItems oder totalPrice sowie Funktionen wie addProduct oder addPromotionCode bereit. So lassen sie sich verwenden, ohne sich viele Gedanken über die zugrunde liegende API-Logik machen zu müssen.
Allerdings ist die Qualität einiger Shopware-Composables unserer Meinung nach nicht auf Produktionsniveau. Das Composable useProductAssociations nimmt z.B. Optionen entgegen, die keine Wirkung haben, da der Verarbeitungscode auskommentiert ist. Es bietet auch keine Möglichkeit, Produktverknüpfungen mit SEO-URLs abzurufen. Daher mussten wir das Composable selbst neu schreiben.
Typensystem
Um Shopware-Komponenten und -Composables effizient zu nutzen, sind korrekt definierte Typen unerlässlich. Glücklicherweise sind alle Shopware NPM-Pakete typisiert und lassen sich gut integrieren. Das Tool @shopware/api-gen ermöglicht die Generierung von Typen aus der OpenAPI-Spezifikation der eigenen Shopware 6-Instanz.
Manchmal decken die generierten Typen jedoch nicht alle möglichen Datenstrukturen ab und können später Probleme verursachen. Zum Beispiel werden in Shopware definierte benutzerdefinierte Felder nicht in die generierten Typen aufgenommen. Stattdessen wird die Eigenschaft customFields so typisiert, dass Entwickler jedes Mal, wenn ein benutzerdefiniertes Feld verwendet wird, den Typ umwandeln oder die Typprüfung deaktivieren müssen.
Erwarten Sie keine “Batteries Included”-Lösung
Der größte Vorteil einer modernen E-Commerce-Plattform ist, dass sie einfach funktioniert - zumindest nachdem man die Konfiguration überwunden hat und bevor man versucht, etwas Ungewöhnliches zu tun oder ein Plugin zu viel zu installieren.
Shopware Frontends versucht gar nicht erst, dieses “Es funktioniert einfach” zu erreichen, zumindest nicht auf der Ebene des gesamten Shops. Man muss bei einer leeren Nuxt 3-Anwendung anfangen und sich selbst bis zu einem voll ausgestatteten E-Commerce-Storefront hocharbeiten.
Es gibt ein von Shopware erstelltes Nuxt-Demo-Shop-Projekt als Ausgangspunkt. Das Shopware-Team weist jedoch selbst darauf hin, dass es nicht produktionsreif ist. Unserer Erfahrung nach ist es am besten, es als Beispiel für die grundlegendsten Shop-Funktionen zu betrachten und nicht als das “Standard”-Theme, das man im normalen Shopware-Storefront hätte.
Warum einen Storefront von Grund auf neu aufbauen?
Dieser Ansatz bietet viel Flexibilität. Der Projektcode kann nach eigenen Bedürfnissen strukturiert werden. Es ist relativ einfach, die Codebasis über mehrere Shops zu teilen (insbesondere mit der Nuxt Layers-Funktion) und den Storefront mit anderen Tools und Diensten über Shopware hinaus zu integrieren.
Das hat jedoch seinen Preis - jede Seite, jede Standard-E-Commerce-Funktion muss explizit implementiert werden. Die von Shopware Frontends bereitgestellten Composables, Komponenten und Hilfsmittel machen es weniger mühsam. Ein solches Unterfangen erfordert jedoch ein solides Verständnis von E-Commerce und eine detaillierte Planung des minimal lebensfähigen Produkts. Kritische und komplexe Teile des Shops wie der Checkout müssen gründlich getestet werden. Shopware stellt eine Reihe von Beispielen und Vorlagen bereit, um Entwickler bei diesem Prozess zu unterstützen.
Anmerkung zu Shopware-Plugins
Ein weiteres wichtiges Detail ist die Kompatibilität von Shopware-Plugins von Drittanbietern. Angenommen, Sie möchten einen Suchmaschinendienst in Ihren Shop integrieren. Bei einem regulären Shopware finden Sie vielleicht ein Plugin, das mit einem Klick die gesamte erforderliche Backend- und Frontend-Funktionalität hinzufügt.
Bei einem eigenständigen Storefront muss das Frontend möglicherweise von Grund auf neu implementiert werden. Erschwerend kommt hinzu, dass das Plugin eventuell nicht für den Headless-Ansatz entwickelt wurde, was bedeutet, dass Sie auch im Backend zusätzliche Arbeit leisten müssen. Das lässt es ein wenig sinnlos erscheinen, Zeit und Geld in die Integration eines Plugins zu investieren, von dem nur ein kleiner Teil genutzt wird.
Leistungsgewinne sind nicht selbstverständlich
Die beiden gängigen Verkaufsargumente für Headless E-Commerce sind Skalierbarkeit und Leistung. Da die gesamte Frontend-Arbeit an Nuxt delegiert wird, wird Shopware nur zum Abrufen der Daten und zum Ausführen von Aktionen abgefragt. Eine solche modulare Architektur ermöglicht eine effizientere Nutzung der Infrastrukturressourcen und mehr Flexibilität bei der Datenverarbeitung und -zwischenspeicherung.
Man kann Daten zwischen mehreren Seiten teilen und auf Seitenebene zwischen SSR, clientseitigem Rendering oder sogar statischem Rendering während des Builds wählen.
Liebe zum Detail ist unerlässlich
Wie wir wissen, kommt mit großer Macht auch große Verantwortung. Da die meiste Datenverarbeitung hinter den von Shopware bereitgestellten Composables verborgen ist, ist es leicht, den Überblick darüber zu verlieren, was abgerufen wird und wie oft.
Fragen Sie nur genug Daten ab, um die Anzeige und Interaktion zu bewältigen, und nicht mehr? Sind Sie sicher, dass ein importiertes Composable eine clientseitige Zwischenspeicherung implementiert hat, so dass nicht eine weitere Anfrage gesendet wird, wenn ein anderer Entwickler dieselben Daten in einer anderen Komponente verwendet?
Das sind nur die grundlegendsten Fragen, die sich ein Frontend-Entwickler stellen muss, wenn er mit Shopware Frontends arbeitet. Die Nuxt DevTools und der Netzwerk-Tab des Browsers sind zwei unglaublich hilfreiche Werkzeuge. Performance-Audits müssen von Zeit zu Zeit durchgeführt werden, um Probleme zu erkennen, die unweigerlich durchrutschen werden.
Was man von der Shopware API erwarten kann
Die Store API von Shopware 6 bietet generell viel Flexibilität und Präzision. Einzelne Entitätsfelder können ein- oder ausgeschlossen, Assoziationen direkt abgefragt und spezielle Request-Header können steuern, ob Zusatzdaten (z. B. SEO-URLs) der Antwort hinzugefügt werden sollen. Auch die API-Dokumentation ist zur großen Freude der Entwickler von hoher Qualität.
Allerdings vermissten wir ein dringend benötigtes Feature – den ETag-Header. Bis Shopware 6.6 gibt es keine Möglichkeit zu prüfen, ob eine gecachte Ressource noch verwendbar ist, ohne den vollständigen Inhalt erneut zu senden. Bei einer Implementierung würde dies die Möglichkeiten zur Performanceoptimierung für Shopware Frontends enorm erweitern.
Nicht zu vergessen: Die Developer Experience
Der Faktor, der bei technischen Entscheidungen oft vergessen wird: Das Verhältnis von Freude zu Frust im Arbeitsalltag der Entwickler hat einen immensen Einfluss auf den Projekterfolg. Wie schneiden Shopware Frontends in dieser Hinsicht ab?
Eine gute Wahl für Teams mit weniger PHP-Erfahrung
Obwohl PHP nach wie vor die dominierende serverseitige Programmiersprache ist, lässt das Interesse neuerer Entwickler an PHP seit einiger Zeit nach. Da Websites immer anspruchsvoller in der Gestaltung wurden, hat der einst unerreichte PHP-Templating-Mechanismus Mühe, mit der Flexibilität moderner clientseitiger Frameworks mitzuhalten, zu denen viele Entwickler tendieren.
Es ist wichtig zu beachten, dass Ihr Team bei Shopware Frontends weiterhin erfahrene PHP-Entwickler benötigt, um am Shopware-Backend zu arbeiten. Die Frontend-Entwickler können sich jedoch ausschließlich auf die Arbeit mit Nuxt konzentrieren und mit Shopware selbst nur über die REST-API interagieren.
Kompatibilität von Shopware Frontends mit anderen Nuxt-Tools
Hier bekommen Shopware Frontends definitiv ein Plus von uns. Die bereitgestellten Bibliotheken schreiben dem Code keine bestimmte Struktur oder Muster vor und die Entwickler arbeiten damit wie mit allen anderen Komponenten eines Nuxt-Projekts. Abgesehen von den erwähnten Problemen mit der mangelhaften Codequalität und der Typabweichung war unsere Erfahrung mit Shopware Frontends recht angenehm.
Implementierung und Testen der interaktiven Teile
Die Nuxt- und Vue-Ökosysteme bringen viele leistungsstarke Tools zur Entwicklung und zum Testen von interaktivem Verhalten im Storefront mit. Reaktive Komponenten sind mit dem Standard-Shopware-JS-Plugin-System bekanntermaßen schwierig zu implementieren, während Vue Reaktivität von Haus aus bietet.
Die Vue Composition API ermöglicht es Entwicklern, clientseitige Geschäftslogik in kleine und überschaubare Teile aufzuteilen, was Boilerplate und Code-Wiederholungen reduziert. Mit mehr Tools zur Verfügung neigen die interaktiven Elemente jedoch naturgemäß zu mehr Komplexität und damit zu Fehleranfälligkeit.
Glücklicherweise erleichtert die erhöhte Modularität auch das Testen des Codes. Bibliotheken wie Vue Test Utils und Vitest lassen sich leicht zum Schreiben von Unit-Tests integrieren. Dies hilft, Fehler zu vermeiden und trägt generell zu einem stabileren Storefront bei.
Abschließende Gedanken
Shopware 6 bietet ein großartiges Basistheme für eine E-Commerce-Website. Größere Änderungen an der visuellen Seite und der Funktionalität des Storefronts erfordern jedoch ein Team erfahrener PHP-Entwickler mit einem guten Verständnis der Shopware-6-Codebasis selbst.
Wenn Sie viel Flexibilität und Kontrolle über den Storefront benötigen und kein mit Shopware 6 vertrautes Team haben, ermöglicht Ihnen das Shopware-Frontends-Toolset, die Leistungsfähigkeit eines modernen Frontend-Frameworks zu nutzen, um eine hochgradig angepasste Lösung für Ihre Anforderungen zu erstellen.
Es ist jedoch nicht immer der Fall, dass Shopware Frontends eine bessere Lösung ist als die Verwendung des Standard-Shopware-6-Templating-Systems. Für kleinere Teams mit einem eher standardmäßigen Anforderungskatalog für den Shop bietet Shopware Frontends möglicherweise nicht so viele Vorteile, erfordert aber eine größere anfängliche Investition, um alle Seiten nahezu von Grund auf einzurichten und zu implementieren.
