PWA is not a silver bullet for all your performance issues, nor is it the definitive best way to build front ends for webshops. What it does offer is unrivalled creative freedom, a superior User Experience, and ease when integrating complex application landscapes if applied in the correct scenarios.
In this article, we’ll take a look at what sets Shopware PWA apart from other solutions, when and where to apply it, and the skill set needed by the team to build and maintain a Shopware PWA project.
With a headless API first back end and a PWA Single Page Application as front end, Shopware 6 has been built with all the right components for a powerful decoupled setup.
While working on introducing Shopware PWA toShopware 6.3, the team quickly identified the need for a more powerful API. While the original Sales Channel API did give read and write access to the required data, it didn’t do so in an optimised manner.
With the introduction of the new Store API, Shopware 6 now offers an API tailored to the data requirements and operations of Single Page Applications such as Shopware PWA.
Take for example adding a product to cart. While adding to the cart we want to perform other actions such as checking stock, retrieving a specific price for the customer, and applying any other checks one might expect from a webshop. When an error occurs we want this to be served back to the front end containing sensible and actionable information for the user. And when the action is successful we want to know the state of the updated cart. Preferably all in as few API calls as possible to improve performance.
On the front end side of our PWA application, we want a clean and modularised setup that allows us to use what we need, and replace or augment where necessary for our project.
By keeping code separated in smaller, purpose-built bundles it stays maintainable and keeps the application size down.
While the back end server and front end application are physically separated, they have been built to specifically work together. This means many concepts familiar to Shopware back end developers can be found in the front end application. As well as each part of the application fine-tuned to the specific Shopware-way of working.
Shopware has provided a way for 3rd party modules to contain Shopware PWA components, making the wider ecosystem compatible with the new Shopware PWA front end. With this being an official part of Shopware 6 we can be sure Shopware PWA stays compatible with future new releases.
Shopware PWA is no silver bullet that fixes all performance issues or brings development costs down. Shopware PWA delivers the most return on investment when applied to cases where a decoupled PWA front end excels most.
We won’t go through all possible use cases, but highlight two that are a sure bet.
Often projects consist of complex integrations and extensive custom plugins that change the behaviour of Shopware to match the offline business processes. But what if the project focus is on the front end? Imagine a project with little custom back end code, but a revolutionary front end design, aiming to deliver unmatched User Experience.
With ShopwarePWA being a decoupled front end application, separate from the back end, there are fewer constraints when it comes to building unique design features. As long as there is an API to populate data with, or write data to, you can build it.
Shopware PWA offers a solid base for any front end, with the components included in the default theme and the Storefront UI library. It also remains easy to style these components, or replace and add custom ones specifically crafted for a project.
One of the unique benefits of running a PWA application is a truly standalone front end which can perform powerful operations.
Often we integrate third party services and APIs in Shopware because of data that we might need to take in, or write to this service. We are forced to normalize data to the platforms’ standards, and then expose it on the front end.
Perhaps one of the best examples is payment and shipping plugins. For Shopware, only the result of a payment or choosing a shipping method is important. Still, we integrate a specific Shopware plugin just to display some fields and options in the checkout.
What if we could skip that, and implement a Shipping Packing stations selector, or a Payment plugin directly in the front end application, where it is needed, and use the Shopware plugin solely to process the result of what was done in the front end.
And this goes beyond the checkout. Shipment tracking information can be pulled directly into the Account pages. Newsletter subscriptions are pushed from the front end to your email provider without any Shopware plugin, and product recommendations can be loaded by API from a recommendation engine without the need for a back end integration.
These possibilities shift the weight of integration development away from back end developers and allow front end developers to tackle this directly.
So there you have two small examples that highlight the new possibilities, but also the impact in terms of skill set requirements for a team. Although Shopware 6 will always be a server oriented PHP application that offers a more traditional twig template engine powered HTML front end, it opens up possibilities for a new generation of Shopware development team.
We see here an opportunity to create smaller, more nimble and fast moving teams that can spin up prototypes quickly or dive deeper into delivering unique ecommerce experiences.
As a Shopware agency, this opens up a whole new market for recruitment. As we all know, finding PHP developers is definitely not easy, and having the possibility to recruit JS developers is a welcome opportunity.
Shopware 6 has been, in terms of technology, a huge leap forward for the Shopware community. And Shopware PWA doubles down on that by introducing new ways of developing ecommerce applications. A big opportunity for both tech-savvy agencies and merchants to step up their game and deliver the next generation of ecommerce experiences.