Shopware Frontends — the way to go for Shopware 6?
Serhii KorzhReading Time: 7 minutes
When considering which e-commerce platform to choose for your shop, many pay close attention to the look and feel of the storefront. Yet what’s arguably more important is how much flexibility the platform provides in modifying and extending the design and client-side functionality.
When it comes to the “sane defaults” storefront, Shopware 6 is hard to beat, while modifying pages using Twig templates is intuitive and familiar to many PHP developers. There is, however, another approach now available — Shopware Frontends.
Enabled by Shopware’s extensive Headless API, Shopware Frontends is a collection of packages for Vue.js that provide CMS components, the API client, composables (reusable blocks of business logic), API types schema for TypeScript support, and other utilities meant to be used in a Nuxt project. With it, you can completely ditch Twig templates and create a highly customizable, highly interactive storefront using modern tooling familiar to many front-end developers.
As with everything, Shopware Frontends comes with its set of benefits and drawbacks, so it begs the question: why choose Shopware Frontends over the default storefront for Shopware 6? Let’s break it down.
What does Shopware Frontends provide?
Shopware Frontends is not a single framework, but rather a number of NPM packages that work in tandem. These include the Shopware API client, Vue 3 composables and CMS components, a Nuxt 3 module, as well as helper utilities and even an API types generation tool.
These packages can be used in a variety of contexts: a standalone Nuxt storefront, a plain Vue app embedded in a standard Shopware storefront, or within a project powered by Astro. In this analysis, we will focus on using Shopware Frontends for building a Nuxt 3 application.
Components
We are generally happy with the quality of Shopware provided CMS components. It is straightforward to add them to a page, and the type system aids with passing the correct data to them. The CMSPage component allows to easily delegate page content management to Shopware Experiences in the Admin panel.
Overriding CMS components is also simple. As long as the input-output types aren’t changed (i.e. props and events) there is little that could go wrong. One thing to pay attention to is that the same CMS component might be used in several pages and other CMS components, so additional props can be passed to help distinguish these use cases.
Composables
The part that immensely helps building a custom storefront with Shopware Frontends is composables. They allow frontend developers to quickly implement core shop logic by providing them with ready-to-use methods and representations of data that handle API interaction opaquely. For example, if you need to display some data from the cart, or modify its contents, you can simply call the useCart composable in your page or component, which provides reactive properties like cartItems or totalPrice, as well as functions such as addProduct or addPromotionCode. Thus, you can simply use them without worrying much about the underlying logic of calling the API and processing the data.
However, the quality of some Shopware composables is not production-level, in our opinion. Take the composable useProductAssociations which (at the time of writing) takes in options that have no effect since the code for processing them is commented out, and does not provide a way to fetch product associations with SEO URLs included. Thus, we had to re-write the composable ourselves.
Type system
In order to use Shopware components and composables efficiently, properly defined types are absolutely essential. Fortunately, Shopware’s NPM packages are all typed and integrate well with each other.
The @shopware/api-gen utility allows generating types from the OpenAPI specification of your own Shopware 6 instance. Sometimes, though, the generated types fail to cover all the possible structures the retrieved data can have, and thus may cause troubles down the road. For example, the custom fields defined in Shopware won’t be included in the generated types, instead, the customFields property is typed in a way that forces developers to coerce the type or disable type checking altogether every time a custom field is used.
Don't expect a "batteries included" solution
The greatest advantage of a modern eCommerce platform is that it just works, that is, after you get through the hurdle of configuring it and before you try to do something unusual or install one plugin too many. Shopware Frontends doesn't try to achieve this "just works" whatsoever, at least, not on the level of the whole store. You have to start basically from a blank Nuxt 3 application and build your way up to a fully fledged eCommerce storefront yourself.
There is a Nuxt demo store project created by Shopware which you can use as a starting point. However, the Shopware team itself notes that it is not production-ready. In our experience, it is best to treat it as an example of most of the basic shop features, and not like the "default" theme you would have in the standard Shopware storefront.
Why build a storefront from scratch?
This approach comes with a lot of flexibility. The project code can be structured according to your needs and desires, it's fairly easy to share the codebase across several stores (especially using the Nuxt Layers feature), and integrate the storefront with other tools and services beyond Shopware.
There's a big cost to it—every page, every standard eCommerce feature must be implemented explicitly. Yes, composables, components, and helpers Shopware Frontends provide do make it much less tiresome. However, such an undertaking requires a solid understanding of eCommerce, and a detailed planning of the minimum viable product, while critical and complex parts of the store like the checkout must be rigorously tested. Shopware provides a number of examples and templates to guide developers in the process.
A note on Shopware plugins
Another important detail to keep in mind is the compatibility of 3rd-party Shopware plugins. Say, you'd like to integrate a search engine service into your shop. With regular Shopware, you might find a plugin that adds all the necessary functionality on the backend and frontend with a click of the 'Install' button. With a standalone storefront, however, the frontend may have to be implemented from scratch. To add to the woes, the plugin might not be developed with the headless approach in mind, which means you need extra work on the backend as well. This makes it feel a bit pointless to spend time and money incorporating a plugin of which only a small part will be utilized.
Performance gains aren’t a given
The two common selling points of Headless eCommerce are scalability and performance. With all the front-end work delegated to Nuxt, Shopware is queried only for fetching the data and performing actions. Such modular architecture allows for a more efficient use of infrastructure resources and more flexibility for data handling and caching. You can share data between multiple pages and choose between SSR, client-side rendering, or even static rendering during the build on a page-by-page basis.
Attention to detail is essential
As we know, with great power comes great responsibility. With most data handling obscured behind Shopware-provided composables, it's easy to lose focus of what is being fetched and how often. Do you query for just enough data to handle the display and interaction, and nothing more? Are you sure an imported composable has client-side caching implemented, so that when another developer uses the same data in a different component, it won't send another request?
These are but the most basic questions a frontend developer must ask themselves when working with Shopware Frontends. Nuxt DevTools and the browser's Network tab are two incredibly helpful tools to utilize, and performance audits must be conducted from time to time to catch issues that will inevitably slip through.
What to expect of Shopware API
Generally, the Store API of Shopware 6 provides a lot of flexibility and precision. Individual entity fields can be included or excluded, associations queried in-place, and special request headers can toggle whether auxiliary data (e.g. SEO urls) should be added to the response. The API documentation is also of a high standard, to the great delight of developers.
However, we found one much needed feature to be missing — the ETag header. As of Shopware 6.6, there is no way to check if a cached resource is still good to use without re-sending the full contents. If implemented, this would vastly increase the extent of possible performance optimizations for Shopware Frontends.
Last but not least: Developer Experience
The factor that's too often forgotten when making technical decisions. The joy-to-frustration ratio in developers' day-to-day work has an immense influence on project success. With that in mind, how does Shopware Frontends fare in this regard?
A good choice for teams with less PHP experience
While still being by far the dominant server-side programming language, the interest in PHP among newer developers has been waning for a while now. As websites became more visually demanding, the once unmatched PHP templating mechanism struggles to compete with the flexibility of modern client-side frameworks, which many developers gravitate to.
It is important to note that with Shopware Frontends, your team still needs to have experienced PHP developers to work on the Shopware backend. However, the frontend developers are able to focus solely on working with Nuxt and interface with Shopware itself only via its REST API.
Compatibility of Shopware Frontends with other Nuxt tools
Here, Shopware Frontends definitely get a plus from us. The provided libraries don't impose any particular structure or patterns on the code and developers engage with them just like with any other components of a Nuxt project. Apart from the aforementioned problems with subpar code quality and type mismatch, our experience working with Shopware Frontends has been rather pleasant.
Implementation and testing of the interactive parts
The Nuxt and Vue ecosystems bring a lot of powerful tools to develop and test interactive behaviour on your storefront. Reactive components are notoriously difficult to implement with the standard Shopware JS plugin system, while Vue offers reactivity out of the box. The Vue Composition API allows developers to split client-side business logic into small and manageable bits, reducing boilerplate and code repetition.
However, with more tools at disposal, the interactive elements naturally tend to be more complex and thus prone to bugs. Fortunately, increased modularity also makes the code easier to test. Libraries such as Vue Test Utils and Vitest can be easily integrated for writing unit tests. This helps avoid bugs and generally contributes to a more stable storefront.
Final thoughts
Shopware 6 provides a great base theme for an e-commerce website. However, making major changes to the visual side and functionality of the storefront requires a team of experienced PHP developers with a good level of understanding of the Shopware 6 codebase itself. If you need a lot of flexibility and control over the storefront, and you don't have a team familiar with Shopware 6, the Shopware Frontends toolset allows you to harness the power of a modern frontend framework to build a highly custom solution for your needs.
However, it is not always the case that Shopware Frontends is a better solution than simply using the standard Shopware 6 templating system. For smaller teams with a more standard set of requirements for the shop, Shopware Frontends might not offer that many benefits, while coming with a bigger upfront investment to set up and implement all the pages nearly from scratch.
