The future of Shopware PWA

Our goal with Shopware PWA is to enable developers to build ecommerce websites with a clear separation between client and server, allowing our merchants to obtain a higher level of ownership and control in custom ecommerce projects. In this blog article we have compiled a short summary of what happens next with Shopware PWA and all the details you need to know.

Within the past two years, Shopware PWA has served as a successful base for dozens of ecommerce projects. However, we’re feeling it hasn’t quite reached the point of allowing us and our users to fully leverage the potential of headless ecommerce implementations.

The real goal of headless ecommerce is unleashing unlimited capabilities in the customer experience. Using a frontend that can comprise everything you want, but no more than you need, allows for a sharp and fully customized online store. Whether performance, individualized content, data fetching, or infrastructure – merchants can perfect every aspect of their CX.

This concept is at odds with the idea of providing a fully-fledged solution like Shopware’s default storefront. And for that reason, Shopware PWA will be positioned at the right end of the customization spectrum:

The challenge with themes and extensions

In the past years Shopware PWA has grown complexities in multiple layers, for example:

• Build complexities due to language configurations and plugin dependencies
• Update complexities due to slots, UI framework dependency, and stronger coupling between UI and lower-level framework
• Development complexities due to various extension mechanisms, such as
  • plugin slots
  • component overrides and (multi-level) theme inheritance
  • event interceptor system

We’ve introduced these extension systems to allow third parties and project developers to build extensions that are integrated into the Shopware PWA default theme and fully compatible. The plug-and-play approach was known to most Shopware developers and delivered an apparently improved time-to-market. However, requirements were so different, and our extension APIs were too rigid to provide helpful entry points for most real-life integration scenarios. In addition, our default theme had been over-engineered with extension mechanisms to a point where it was impossible to benefit from the original advantages of the standalone (headless) frontend approach.

We realized that spending more resources on a default theme would be a waste of time and efforts. Instead, we want to focus on the underlying framework functionalities that integrate with Shopware’s API and make them easy to use. We want to deliver concise and useful examples for every moving part of an online store, such as listing and filtering, product variants, payment procedures, or cart checkouts. And we want to remove the setup barrier for creating a working solution from an initial idea.

Our improved approach

In the space of JavaScript technologies, frameworks and tooling iterate very fast – in a way that makes it hard to keep up with all latest versions. Our goal is not to join that race, but instead provide a more framework-agnostic approach to developing custom storefront solutions. We offer composables as a set of portable functions that can be “dropped” in with the frameworks you like. We’ll refer to that set of functions as the “Composables API” or just “API”.
For now, we’re going to focus on the Vue.js ecosystem as Vue.js is close to Shopware and has a solid base for us to expand upon. The Composables API relies on core patterns of Vue.js, like its Composition API, reactivity, provide/inject, and several other parts of the framework.

The state-of-the-art framework for scalable Vue.js websites is Nuxt.js which provides a solid foundation for building Vue.js applications – with a strong focus on performance, SEO, and a great developer experience. For that reason, we’ve decided to create a reference implementation using Nuxt.js. This reference implementation is distributed as a “boilerplate” rather than a theme, so it can be used as a starting point or just a “look up” for custom implementations.

However, we believe that the approach of headless, API abstraction, and composable business logic goes way beyond Vue.js and even beyond Javascript. Our long-term vision is to create a more generalized, abstract API that can be used as a base for any custom frontend implementation. We’ll closely observe the development of different ecosystems and provide more specific reference implementations along the way. The first step in that direction could be an implementation of our Composables API as React.js hooks. This will open up Shopware’s API to an even broader audience of talented developers.

Why “composables”

The name “composables” has been introduced by the Vue.js team as a response to React’s “hooks” concept. It’s a concept that allows you to extract reusable logic from your components and share it across your application – like the concept of services, but more oriented around view logic.

We picked up this concept and applied it to our own implementation. The idea is to provide logical, coherent, and self-contained units of functionalities that provide easy access to a specific business domain of Shopware’s API – like checkout, user registration, product filtering or cart operations. Composables allow us to create a layer of UI logic and business logic on top of the Store API. This way developers don’t need as much knowledge about the APIs inner workings. We’ve designed composables in such a way that they provide intuitive access to data and actions. As a result, developers can focus on building the best possible user experience.

export type UseProductPriceReturn = {
    /**
     * Whole calculated price object
     */
    price: ComputedRef<CalculatedPrice | undefined>
    /**
     * Current price value
     */
    unitPrice: ComputedRef<number | undefined>
    /**
     * Can be used if isListPrice is set to true
     */
    referencePrice: ComputedRef<ReferencePrice | undefined>
    /**
     * determines if `price` contains the minimum tier price
     */
    displayFrom: ComputedRef<boolean>
    /**
     * cheapest price value for a variant if exists
     */
    displayFromVariants: ComputedRef<number | false | undefined>
    /**
     * array of TierPrice object
     */
    tierPrices: ComputedRef<TierPrice[]>
    /**
     * determines whether a discount price is set
     */
    isListPrice: ComputedRef<boolean>
}

export declare function useProductPrice(
    product: Ref<Product>
): UseProductPriceReturn

The same goal

We’re still convinced that abstraction through decoupling is key for building custom, high-end UX websites that outperform their competition. We’ll continue to pursue that goal and refuse to bloat the software with convenience features that compromise its flexibility. And we’re confident that our partners and merchants will benefit from that focus in the long run.

The future of Shopware PWA

We decided to restructure the Shopware PWA project and move it to a repository, for now called Shopware Frontends (working title). It’ll still contain parts of the existing codebase – specifically composables and helpers, but comes with an overall polished documentation, types, and a new reference implementation. We’ve learned that current PWA projects are challenged by the same, common problems and we’re addressing all of them in the new version.

How should you start a new project?

We recommend that any new custom implementation should start with the new code base rather than the Shopware PWA packages. It’s based on production-tested code and contains a lot of improvements. Our setup templates offer you a head start with increased flexibility over the old versions. The current API might change in small places, but these will be documented and announced in the release notes of all RC versions. With every update you will be able to upgrade your project gracefully and by the time we release the first stable version, your project will be up to date.

Is there a migration path?

All projects built on Shopware PWA are custom implementations and the codebase of these projects is a custom codebase. There will be no generalized migration path for custom codebases. However, the old and new API are very similar, and you’ll be able to incrementally migrate your project if you want to benefit from the new API.!

What about the old version?

You don’t need to update your project to the new API. The old API will be supported for the time being and Shopware PWA will not become “unstable”. We will observe package traffic and decide on a timeline for the end of support for the old packages. Shopware PWA will get further maintenance support which includes bug fixes and security updates.

I’m currently building a project based on Shopware PWA. What should I do?

Don’t worry if you’re currently building a project based on Shopware PWA. Both Shopware PWA and the new framework share the very same architecture and you can build the same projects based on Shopware PWA with Shopware Frontends. We consider Shopware PWA a more capable “reference implementation” but with a limited ability to update (as compared to Shopware Frontends, where there’s a no update-approach). However, we’ve observed that some patterns adopted in Shopware PWA lead to higher project complexity. For example:

• When the project is based on Storefront UI (difficult to update and customize)
• When plugins that are used as a replacement for customization
• Using component overrides (they are hard to update and maintain)

But with each of those anti-patterns you can opt out at any time during the project. Most likely it’ll reduce your projects’ complexity right away.

The child’s name

Building a framework for custom ecommerce solutions is a big task. Not only do we want to provide sensible APIs and a solid documentation, but also manage expectations and build knowledge. We’ve decided to give Shopware PWA a new name which will be announced soon. This will help us to better communicate our vision and the direction we’re heading. In the meantime, the working title is “Shopware Frontends” which is also the name of the new repository shopware/frontends.