Scaling Commerce with Shopware Composable Frontends?

Yesterday I attended the Kellerkinder BarCamp 2023 in Mannheim. There was a discussion about a project with 15 sales channels, 150,000 products, even more variants, and many different domains/languages. A pick-up functionality was also involved. The main question, in that discussion, was always: Will Shopware scale or when will it stop scaling? Furthermore, each sales channel has exactly the same products, descriptions, and images, so there are no differences.

Spoiler Alert: It's never a good idea to create redundant data just to have 15 storefronts with different domains and duplicate products/content. This also slows down administration and does not benefit users. From my point of view, this is a really underrated topic to help your customer manage their data in an effective way. In a perfect world, you wouldn't have 15 sales channels with the same data because you want to create one strong online store and not 15 undervalued duplicated stores.

But we don't live in a perfect world, so what alternative would there be to solve this problem?

• Create one SalesChannel with all the Languages and all the Domains you need
• Import once all the product data. No redundant data
• Extend the Order (CustomField, Entity Extend aka Extensions)
  ➡️ CustomField would be the simplest solution, but if you need a filter in the administration, an extended entity would work better
  ➡️ Use these new fields/data for the ERP export to be able to differentiate between the domains and languages
• Use all the product data headless with Composable Frontends via the new API client
• Use Vercel, Netifly, or something else for the Frontends Deployment (decoupled from Admin, you can manage the Frontend-Domains there)
• Use a mono repo, so you have the possibility that all 15 sales channels are using the same template or you can use Nuxt layers to change some parts of the template for some sales channels to have it more custom
• During checkout, you send the CustomField or Data for the extended Entity via store API to the Shopware Admin (later you can use that for ERP export or notifications and so on)

Benefits? Your database will not reach its limits for much longer. The loading times when working in the admin area remain fast. Updates will be easier cause you only rely on the store API.

Downsides? You cannot use every plugin from the marketplace (requires support for the store API). You may need to create some parts from scratch that are not currently available as composables/components. You may need other developers who like to work with TypeScript/JavaScript.

TL;DR 🤯

Don't create redundant data just to use the default storefront. During programming, we don't repeat ourselves, so why would we create redundant data to solve a problem when we can use the same data with a headless approach?