Shopware Frontends

Recently, we announced that we are working on a project called “Frontends”. This blog article deals with the What, Why, and How.

In short, Shopware Frontends is a framework or a loose set of tools/functionalities related to frontend development. These tools aim at accelerating the prototyping and development of custom ecommerce storefronts with Shopware 6.

What is frontend development?

First, let’s set clear boundaries for the term “frontend” as it’s used in “frontend development”. As we are resting in the general space of ecommerce - frontend relates to everything that affects a customer/buyer/shopper during their buying journey. This implicitly includes applications like

Ecommerce Websites
Native Mobile Applications
Single Page Applications (SPA) & Progressive Web Applications (PWA)
IoT Applications (e.g. smart speakers or dash buttons)

Development is the procedure of implementing business requirements in any of the application domains above.

→ Frontend Development

What is prototyping?

Prototyping is a common practice when developing software. Usually, when a software project becomes complex, you break it up and define “core” requirements. These core requirements are associated with the biggest risk for the successful completion of the overall project.

During prototyping, developers will try to implement the core requirements in a low-stakes environment in order to assert and qualify the validity of a certain approach. The result is called a “prototype”. Secondary measures - such as quality, maintainability, or performance - are consciously overlooked for the sake of providing conceptual insight and evidence in a short time. Of course, these measures can vary depending on the goal of the prototype.

The ability to prototype quickly can be of immense benefit to the overall business agility and innovative capabilities of an enterprise.

What’s our take on custom ecommerce storefronts?

We are observing different approaches that project implementations can use to achieve a non-standard storefront. Depending on the degree of customisation, it is critical for project success and maintainability to choose the correct approach.

Shopware has always been following a theme inheritance approach, which provides a great mix of flexibility, stability, and features. However, we see that this approach has some limitations - which we are trying to address with our new open source framework - “Shopware Frontends”. But let’s start with an overview.

Approaches to customisation

Going from rather standardised to highly customised, you can generally differentiate between four approaches

Configuration-based - change colours, fonts, margins, logos
Theme-based - choose between pre-built, configurable themes
Theme inheritance based - have a general structure defined by a “parent” theme but define individual markup and styles
Custom or API-based (headless) storefront - no pre-defined structure, plain field approach
Customer experience platforms - dedicated content “heads” with extensive configuration options
Custom implementation - custom projects, based on frontend frameworks or templating engine

Theme inheritance

Most modern ecommerce “suites” (platforms that cover all components of an ecommerce store - frontend, backend, API, …) - such as Shopware 6 - provide a theme inheritance-based customisation approach for storefronts.

This approach is extremely powerful as it provides an architecture very open to customisation, without compromising on features and 3rd party extensibility. And it provides a LOT of features out of the box.

However, theme inheritance is also limiting in multiple respects

It ties you to a pre-defined global site and page structure based around controllers and templates
It forces you to stick to a very strict block-based extension API in order to remain compatible with future releases of the “parent” theme, and 3rd party extensions
And even if you stick to this extension API, major updates will include breaking changes that you need to work out manually. If you consider the dependency matrix of your project, 3p extensions, and the parent theme - this can lead to huge efforts with growing customisation of your project.
New features with the parent theme come “for free” - but that’s not always what customers want, so it may become an unwanted side-effect of updates
It’s opinionated - styling framework, naming, and client logic (JS) are very hard to modify/remove

API-based implementations

This is where API-based implementations come in. They turn the dependency hierarchy inside out, by only subscribing themselves to a fixed, stable, and more manageable API (namely, the Store API in Shopware 6). Everything else is built on top of that and is not bound to any of the limitations mentioned above.

So, if these liabilities are limiting your achievements in customer experience, you should consider building a custom storefront.

Shopware Frontends follows the API-based implementation approach. It fills the gap between a theme-based implementation and a fully custom headless implementation, which is usually accompanied by uncertainty and risk.

It does so, by subscribing itself to five key assumptions:

Start on a green field

We believe API-based implementations require as little boilerplate as possible. For that reason, we just offer so-called setup templates - which provide a starting point for your project. They contain little markup to help you get going. Their main idea, however, is to be understandable and suggest how an implementation can look. Feel free to copy-paste code or tear them apart to your liking. It’s your playground.

→ Check out the starting grounds for Shopware Frontends

Provide useful components out of the box

Even for very custom projects, there are some parts that should be reusable. We have decided to give special attention to our beloved Shopping Experiences. For that reason, Shopware Frontends comes with a Tailwind.css implementation of all sections, blocks, and elements in our Shopping Experiences. We also provide Typescript definitions and helpers, so integrating the CMS into your site comes more easily.

→ See how we provide reusable CMS elements

Encapsulate API functionality

The API is the only connection between the frontend and Shopware. For that reason, we have spent a lot of time on refining and documenting the internal API - “composables” - so they feel as native and intuitive as possible. Use them to build checkouts, listings, product pages, searches, and account areas without any knowledge about Shopware’s API endpoints, authentication, or parameter naming.

→ Check out our composables and how to use them

Leave the styling out of the game

Styling comes in many different and opinionated ways. For that reason, Shopware Frontends does not force any styling or UI library upon you. However, to please the eye, we provide a reference implementation using Tailwind.css. Utility CSS is the most portable styling and also the easiest to “undo” because it is part of your component markup. Everything is possible - nothing is required!

→ How to apply custom styles or use the on-board framework

Lower the entry barrier

Ironically, headless architectures can cause headaches for many developers without experience in the space. We think that’s not how it should be. Hence, we focussed on providing easy setups that lower the entry barrier for people that want to try out themselves - such as our in-browser IDEs. Needless to say, Shopware Frontends is completely open source and free for anyone to use.

→ Spin up your IDE in seconds

Why build a custom storefront?

It’s safe to say, that the complexity of building custom has significantly reduced with each iteration of APIs, hosting platforms, frontend frameworks, and CSS libraries.

We are building Shopware Frontends to pick up on that momentum and complement various dimensions

Atomic / Utility CSS (Tailwind, unocss, Windy CSS)
Serverless hosting
API-abstraction
Client-side state handling and logic
Static site generation and edge-delivery
Integrations with frontend frameworks / bundlers like Vite, Vue3, Nuxt.js
In-browser IDEs
Fully automated deployment cycle

That said - it doesn’t force any of the technologies/approaches above. The goal of Shopware Frontends is to complement custom implementations and the stack is designed to be opt-in from bottom to top. If you’re building an app - you probably just want to use the API integration layer (api-client). If you want to build a static site - consider using a server-side rendering framework like Astro together with Shopware Frontends.

So custom storefronts all the way!

Do not underestimate the value that comes with theme-based storefronts or in other words, the complexity that lies in a custom build. Things you most likely need to take care of (which can be more complex than anticipated) are

Multi-domain / multi-store routing
Translation handling
Variants handling and product configurations
Payment handling
Hosting and performance optimisations

Before taking on an ecommerce project using Shopware Frontends, you should be confident about Vue.js, headless implementations, and its stumbling blocks. If you are interested in building a custom storefront, talk to us, and let’s discuss whether Shopware Frontends can benefit your project.

Shopware Frontends Documentation