Shopware Community Unconference 2022 Recap

First of all I (Niklas) have to say that I enjoyed the event really much and want to thank Firegento for the organisation.
Here are my key takeaways from some different sessions I attended and from many talks I had:

Headless Shopware - Open discussion

One of the first sessions was actually led by myself, and I was happy that so many people showed interest in using Shopware as a headless platform. The topic of the session was to have an open discussion and exchange of experiences with using Shopware in a headless way.
What I saw during the session was that the interest in this topic was high, but not many people actually have tried it, because there are many uncertainties and questions in many areas. One of them is the support of the plugins/apps: Right now it's not really visible from the outside (e.g. in the plugin/app-store) if a plugin fully supports headless usecases. This makes it difficult for merchants/agencies/developers to evaluate beforehand, if the required functionalities crucial for the current project are already available also for headless, especially without investing too much time and resources. A suggestion came up that it would be great if there was a flag in the store that shows if the plugin currently supports headless. Speaking of plugins: obviously not every plugin has to support headless. Plugins like themes or Storefront-Extensions by definition won't have to support it. Even ones that do not need to provide new APIs/endpoints (let's say because the whole functionality can be done with the event system) do not have to "actively" support it, because it should work the same for all environments.
There are some best practices provided by Shopware, for example providing the business logic of the plugin through a store-api route, a potential storefront-route would just call the before-mentioned route internally.

The discussion then went more in detail on shopware-pwa as one possible solution for a frontend. I could share some of my experiences of using it and also some challenges that have to be tackled. Some of them can be solved by oneself, some of them have to be solved from Shopware (Spoiler: They will be). Examples for some challenges are caching of the output rendered by the frontend app (see the discussion started on GitHub) or improving the current performance of the Store-API.

In the end an interesting question was raised: how did using a headless setup affect the developer experience for us?
From our experience I can say that this of course depends on the skill set of the developers involved. For us, it was easier to onboard new people (for example trainees), because there is a strong separation between backend and frontend. So people can focus on one area and don't have to worry about the other. Small example: one can focus on displaying the data received from the api in the frontend/ui and doesn't have to worry about where this data is coming from. It makes it even easier to work on both parts more independently, so the other way round the backend developer doesn't have to worry about displaying the data in a nice UI and can focus on providing it through the api. This of course comes with the tradeoff of higher complexity in the whole application, because you have two completely independent applications (frontend & backend) to manage, keep up to date, deploy, etc.

Performance improvements

There are many incoming performance improvements (starting with the upcoming version 6.4.11.0). They'll be behind a feature flag, because some of them are breaking. But it's nice to not have to wait for the next major version by checking if you're affected by those breaks. I obviously can not list the changes here, but I assume they'll be described in the changelogs of the new versions.

New Admin Extension SDK

There is a new way to extend the administration without overriding existing components. It's calledadmin-extension-sdk. I won't get into much detail here, because it's all described on GitHub and the documentation, but here are some key points:

• Provides an interface to extend the administration without tight coupling to the components itself
• All extensions are in their own iFrame, which can communicate isolated with the administration
• There will be extension points in the administration (as I understood it for every admin-component) which can be used to inject something.
• Works for the plugin and app system
• Vue devtools integration to see the available extension points

Best practices of end-to-end testing (with Cypress)

Ramona (Shopware) and Christian (dasistweb) shared their experience on writing good, easy to understand and maintainable e2e-tests. Actually their advice didn't only apply to e2e-tests, but to tests in general. When reading tests they should be telling you what they do by looking at it. This can be achieved on finding a good balance between using/writing reusable test-functionality (e.g. helper functions/classes) but also not over-engineering the tests. For example regarding e2e-tests with Cypress it's always a good idea to keep element-selectors in one place to reuse them, because it makes it much easier to keep the tests up to date if something changes in the application to test.

Developer Documentation

Another session was all about documentation. We discussed the challenges of writing and structuring good documentation both in a general and the shopware context. We focussed more on developer documentation in this session. Key points were:

• It's very hard to write documentation that pleases everyone, because there are many opinions
• When writing docs one should always have the target audience in mind
• Docs need a really good search function with filtering, because you will find things much easier, especially if there is much content

That's all for now, I'm looking forward to see you guys again next time!
Niklas