In general, a “storefront” is the user interface for a shop. This is why a shop can also have multiple storefronts, for example to target different audiences or customer groups. When people are talking about “Storefront” in the Shopware context, they most likely mean the default UI of the shop that comes with Shopware. This UI is based on the templating engine TWIG, Bootstrap and plain Javascript. It is tightly coupled with Shopware itself and can be extended and modified by extensions (Shopware apps or plugins). Like this, you can also use different predefined themes or create your own custom theme.
“Headless” describes more of an architecture approach to how software is built. You differentiate between monolithic and distributed architecture. In short a monolithic application contains every part from the business logic (backend) to the user interface (frontend). As you maybe noticed by now, using Shopware with the provided storefront is more of a monolithic application. “Headless” in contrast to the monolithic application separates between the frontend and the backend: an application is considered headless, if it only provides the business logic through APIs, but no user interface. In the analogy, the frontend is the “head” and the business logic the “body”. Often you also hear the term “headless frontend” which is a bit misleading in my opinion, because it much more should be called “bodiless frontend” ;)
Because Shopware is build API-first, you can also use Shopware in a headless way and provide a completely separated frontend for it. There you can use basically whatever you want, it just has to be able to consume the Shopware API. If you don’t want to start from scratch, you can use Shopware Frontends. It provides you an API client written in Typescript, Vue-composables which encapsulate common use cases for easy reusability and a complete boilerplate implementation for Nuxt/Vue, so you get a big headstart there.
That’s really hard to say. You might not like to hear it, but as always “it depends”!
There are many factors that have to be considered: size/budget of the project, skillsets of developers and team members, level of individualisation, just to name a few.
What we saw in headless projects is that handling Shopware Updates got a lot easier, because you basically only have to deal with the business logic layer, but not the UI (at least if there aren’t any API breaks). But on the other hand, you maybe don’t have such a fast time to market, at least if you’re starting from scratch. Furthermore you have complete ownership over your frontend, which can be a good but also a bad thing.
There are many more things to consider, which are highly individual from project to project, so it would be irresponsible of me to say “use this for that”. But what I can say is that in general you can think about using Shopware headlessly, if you want to use specialized services or systems for specific tasks and only use Shopware in its core features. There the often heard term “composable commerce” comes into play, where you compose your ecommerce landscape from many different services.
