The confusing proposition of Shopware PWA

The conundrum

So what is at hand? Shopware 6 was released years ago as a replacement of Shopware 5, but also with a completely new vision: The architecture is API-first, meaning that the focus is primarily on making sure that third party developers are able to easily extend upon things, while the application follows from this. Headless is one of the possibilities here.

The current Shopware frontend is not headless, but monolithic: Its Twig templates are tightly connected to the PHP backend system. CSS and JS are managed through a PHP mechanism (even though this triggers again some Node). Shopware PWA changes this: In principle, it only relies upon the Store API (and partially, some magic with the Admin API) but the rest is "Just Vue" (tm).

But the conundrum is not really about the architecture (even though I've got some points there): It is more about the fact that Shopware sometimes markets headless as being the future. Shopware PWA is listed as one of the key features of Shopware (on the official site). But is the right positioning? Does the technology live up to this expectation?

Short personal answer: No. And this is why I find the proposition of Shopware PWA to be confusing to say the least.

The architecture of Shopware PWA

Disclaimer: I like headless and I like Shopware PWA. I'm training developers to use it and somewhere these weeks, the Yireo On-Demand course on Shopware PWA goes live. I like it. But I also see and know its disadvantages.

Shopware PWA is based on Vue Storefront 2, which is based on NuxtJS, which is based on Vue. By choosing Shopware PWA, you need to be either a Vue developer or a NuxtJS developer. If you don't have enough knowledge about those tools, your Shopware PWA project will be a disaster. Embrace Vue first.

Additionally, Shopware PWA is not just Vue Storefront 2, it has added its own flavor upon the original Vue Storefront Next architecture as well. This brings both good and bad things.

Making life easy. Question mark?

For instance, there is an integration between the Shopware CMS (pages, sections, blocks and elements) and Vue: Core components are there to support the core CMS Blocks and CMS Elements. And this is fully extensible. I consider this very cool.

There is also an option to allow Shopware plugins in the backend to modify the PWA: This is done through an additional type of extension, which I will refer to as a PWA plugin.

Besides the CMS extensibility and the PWA plugin, there is also an override mechanism in place, which allows you to extend upon the Default Theme. And theoretically you can build your own parent theme.

A lot of features to make life easier. But does it?

How easy should a PWA be?

All in all, the extensibility of Shopware PWA is there to make life easy for traditional Shopware developers: You install a plugin in the backend and voila, the frontend is modified. Unfortunately, a Vue app works a bit different: If the sources of the Vue app are modified (so, a new CMS Block, a PWA plugin or a new component override), the code needs to be transpiled and deployed. Of course, deployment is a thing with a normal Shopware instance too, but we should not forget about the fact that deploying a Vue app adds complexity. The fact that backend and frontend are disconnected by default adds in complexity.

Even more important is the fact that a custom project will need a custom look & feel: Theoretically this could be accomplished with changes in CSS only (CSS Zen Garden anyone?). But usually, the HTML is also modified (duh). With Vue, this means that Vue components are customized. And the more the design and the UI is different from the demo theme of Vue Storefront, the more it makes sense to build your own custom components instead.

This sounds difficult - building components from scratch - but if you are a Vue developer, it's not. Assuming the HTML/CSS design is already there (which has zero to do with Shopware and Vue Storefront), the HTML and CSS code could be picked up and transformed into a Vue components in a matter of minutes. An entire conversion from static HTML/CSS to static Vue components takes merely hours. Obviously, you're not there yet: All Vue components need to be made dynamic, by either rendering a presentational stateless component through some smart parent component that is pushing in dynamic props. Or by using composables. This adds time.

Extending a parent theme is actually not headless

The workflow proposed above is something most Vue (or React) developers take for granted: Take a design, create components and hook them into dynamic functions (composables, hooks). With Shopware PWA, a different approach is suggested: Extend upon a parent theme, auto-insert components into slots, create a component structure based on JSON from an API.

This sounds more familiar to traditional Shopware developers. But it sounds overly complex for an average Vue developer. Where is the composability in that?

Furthermore, the more your own design is different from the demo theme, the more customization you will do, the more your components are better off to be custom-made. Up to the point that maybe even most of the original components have been modified. Legacy goes up. Upgrades become difficult. And at that specific point, you might have been wondering if starting the entire app from scratch wouldn't have been a better idea.

Be a Vue developer first

There are various things wrong in this picture: The extensibility of Shopware PWA makes it easier for newbies to get started. But no matter what, to make it a success, you need to grow from newbie to Vue developer first. And once you become a better Vue developer, building your own components while reusing composable functions from others is a normal thing. At that moment, extensibility becomes something you benefit less from. And it actually makes the architecture harder to understand.

Overriding a component sounds fun at first. Say an app contains a header which contains a logo. And you only want to change the logo: Replacing the entire component tree (app + header + logo) is harder than just replacing the logo. However, what chances are there in a real-life project that you are only going to replace the logo. With most projects, you will need to modify the app and the header as well. Gone is the benefit of overriding components: You will need to own the component tree anyway.

The PWA plugins is yet another thing that sounds great at first, but might complicate things in the end. For instance, the fact that new Shopware plugins could automatically insert their PWA plugin into the PWA might be both awesome and horrific. And what about PWA plugin conflicts? What about PWA plugin ordering? The entire plug-and-play concept is opposite to the Lego-nature of Vue.

There are ways to overcome this yet again, but the point is that it promises to make life easier, while it actually complicates things.

Undoing Shopware PWA

A while back I had a training with a certain agency. And this blog is kind of the sumup of how they felt. They enthousiastically started with Shopware PWA, but in the end felt they should have been building a Vue app from scratch instead. They didn't need PWA plugins, they used an alternative CMS, they created their UiComponent library. And they were stuck with too much complexity to make things easy, while they preferred the Nuxt-only way.

During the training, we therefore set out to separate the good parts from the bad parts. The PWA plugin slot was nullified, so that slots didn't do anything anymore. The Webpack configuration was changed to override in a different way. And the opportunity on dropping most components, in favor of composables, was discussed as well.

Shopware PWA is not a product

This agency felt they were fooled into Shopware PWA as in a solid one-way solution, while in the end they felt a lot of the given functionality to be unstable, simply because they were expecting other features from it. In the end, they would have been happier if they would have choosen a plain NuxtJS setup and then gradually adding Shopware PWA tools to that.

The problem here is - in my opinion - that Shopware PWA is being sold as a product. Its features like PWA plugin and parent theming suggest that developers that are unfamiliar with Vue can easily get started with it. And the product will take care of the complex part. However, e-commerce is often so complex, that it does not require a simple product, but a flexible toolbox instead.

Shopware PWA is not a key feature, the API is

Shopware PWA is such a toolbox too: It offers Vue components to demo all features, it offers solid composables to make creating custom components easiers, it reuses concepts from NuxtJS to offer solutions for paging and SSR, it offers a CMS integration. But the proposition of all these parts being a complete solution is wrong.

Shopware PWA is just one codebase that people can reuse code from to build their own PWA. On its own, it might be offering very interesting features, but within a project, a lot of that needs to be reshaped. And more importantly, the success of a PWA project should not be measured by the completeness of Shopware PWA, but by the knowledgeability of the developers involved.

On the Shopware site, Shopware PWA is sold as a key feature. But to my belief, this is the wrong proposition: Shopware PWA is more of a suggestion, a kickstart for devs, but not a complete solution. Instead, the actual key feature is the Store API, which Shopware PWA leans upon.