Highlights, interviews and a glimpse behind the scenes
For the past nine years Shopware enthusiasts have met up each year at a location in Germany to listen to the latest updates and product rollouts of Shopware. And this year, on June 18 and 19, we celebrated the 10th edition of Shopware Community Day, and 20 years of Shopware. But this year with an online twist to the event.
For two days the Shopware Community Days livestream broadcasted 34 talks, watched by over 3000 participants from all over the world including Germany, Italy, The Netherlands, and Poland, all the way up to Ecuador, Mauritius, and the Philippines.
How did some of the speakers, crew members and visitors experienced the day?
First Björn Meß (Event Manager at Shopware) tells us about this year's organizational challenges:
"We basically planned a very normal community day for 2020 in Duisburg, in the Landschaftspark park, as we did in 2018 and 2019. Around mid-March the local government finally announced events up to that size were prohibited until further notice. The week of the cancellation was quite hard because we didn't know what to do from that point. Do we just cancel the Shopware Community Day completely for 2020? That wasn't an option for us. We are celebrating 10 years of Shopware Community Day, and 20 years of Shopware. We had to do something!"
"I personally, very much enjoyed both days, especially the fact that I could just sit back and watch the live stream. We didn't have to run around to get to a certain room as you normally have to at the conference. I think it was the first time I attended the conference where my legs didn't hurt."
"And Slack worked out well for the networking. It's always a good experience to see that people lose shyness. There were so many people, logging in and chatting about all kinds of stuff and also in the live chat. And the feedback that we got was actually that the QA sessions were too short and that's good. We were unsure of whether this tool would be used to fill a five or maybe even 10 minute Q&A or not, but obviously yes."
The event was streamed live from the Shopware Campus in Schöppingen. Do you want to know more about the production of Shopware Community Day? Read the full interview with Björn down below.
We talk to Joshua Behrens, partner and developer at Heptacom and Shopware Ambassador on how he experienced attending Shopware Community Day 2020.
"This year, it was very easy for me to watch all the talks and there were no technical problems. For an online event that used to be in-person previously it went really well. I was sorry to see the tracks reduced to one main stage because they had one video stream. That means they had to remove lots of the content they wanted to show."
What were some of the highlights for you of the Shopware Community Day lineup?
"One that really stood out was the ‘Matter of trust’ by Ramona and Phillip. I guess it was one of the first talks Shopware Community Day had about testing. It gives an inside view into how they handle testing. We didn't know much about the testing philosophy behind Shopware. So it showed us another perspective of looking at it."
"I also took the information that Dominic had in his Store API talk and compared it to some of the use cases I already had worked on with the Storefront API. So the ancestor of this API that they showed there. I looked to see if it is now easier to get my own end points into that API compared to the old way. It is certainly easier, there are also some new restrictions, but it's a good exchange all in all."
Read the full interview with Joshua about his view on Shopware, his background and more down below.
Fabian Blechschmidt, both speaker and conference attendee, enjoyed his Shopware Community Day:
Keynotes, product presentations and voices from the community
The event kick-off on day one is a keynote by Stefan Hamann, CEO and cofounder of Shopware. Not just talking about the product, we also get a glimpse behind the scenes of the early days of Shopware, and how the company expanded to over 200 colleagues.
Can you remember the first customer on Shopware about who you were amazed such a company would choose Shopware as their platform?
"It was Arktis.de, they were one of our first customers, and it was interesting to have such a big project early on. We learned a lot about scalability for instance. Most shops had 5 or 10 orders per day, ACTIS was doing 100. This improved Shopware as a product early on."
"So that was the birth of Shopware in 2004 and roughly two years later, we released Shopware 2. And in Shopware 2 there were already some mechanics that you can see today. The Shopping Experiences for example, the drag and drop behaviour, was already part of the product in 2006."
Looking at Shopware 6 today, can you identify the decisive moments over the last 20 years that led the company to build Shopware 6, into what it is today?
"The most important development was in 2015, I would say that was the year when Shopware 5 was released. It had the same code base since Shopware 3. We had to make a really hard decision, to write everything from scratch for Shopware 6."
"I believe it was the right decision to start with an established framework, like Symfony from the PHP side, because that speeds everything up. We don't have to invest time in things that have already been developed a thousand times out there and we can focus more on the eCommerce functionality and the core competencies of Shopware."
Read the full interview with Stefan about the evolution of Shopware as a company, the product, and his role down below.
Shopware in the Cloud
Another big product rollout is the new Shopware Cloud. A SaaS version of Shopware 6. Both Jörn Paulsen, Director Product for Cloud Services, and Christian Rades, Core Developer, spoke about the latest addition to the Shopware product family.
"While Shopware 6 was being built we already had something called "playgrounds", which offered a Shopware 6 sandbox to developers. These were hosted on AWS as cloud solutions much like Shopware Cloud is today. This means we already had experience with AWS, as well as a solution that could run in the cloud. The next step was to launch the demo shops used to show Shopware 6 to the world, which were like a further development of the AWS infrastructure. We launched in September of 2019. This year was the third evolution of the SaaS infrastructure. There were a lot of things done to perfect the infrastructure for this multi-tenant solution of Shopware 6 on AWS. I would say that is not just the software that runs on AWS servers, it's a real cloud-native product now."
"I do think there will be some impactful changes for developers. When it comes to creating Apps for Shopware cloud, developers can do this in any language they want, and host it where they want. Most developers who are working with Shopware 6 right now would be able to write a Shopware App system application just like any other web application."
"The actual files you write for Shopware, those are just an interface definition. It describes what events you want to be subscribed to, and what changes you want to do to the UI of the shop. The app is basically two parts. The aforementioned interface description, what we call manifesting XML. And the rest of it is the back end. This is just an application that provides HTTP endpoints which listen to observed events. It communicates with Shopware itself via APIs over HTTPS."
More can be read about the features and functionality of Shopware cloud in the interview with Jörn, and more in depth information on developing apps in the interview with Christian.
And of course there was plenty of content around Headless APIs and PWA.
Dominic Klein, Technical Specialist at Shopware, talks about the new Store API:
"The Key takeaway I wanted to convey in my talk "Introducing Store API" at the Shopware Community Day is the understanding that the shop system, Shopware 6, and the frontend interface are not one stack."
"When you see a platform as one monolithic stack it will restrict the freedom in development. While it might seem convenient to have the opportunity to call your MySQL database even from the template files, for the sake of creating a robust application it is something that you certainly do not want to allow. You want to introduce a level of abstraction in order to craft good software, which allows for better extension for example, which gives developers a broader set of tools to work with and build on."
"I wanted to convey the understanding of having a functional space in the software, and these functions and processes are encapsulated in API endpoints which should be the way external systems, such as a decoupled PWA frontend, interact with your software. And only when you cover a hundred percent of the functionalities in the software with API endpoints do you allow for other software to fully integrate with your core system, which would be Shopware 6 in this case."
Dominic talks more in-depth details on the Store API, and his role at Shopware, in his full interview down below.
Patryk Tomczyk, Lead developer on the Shopware PWA project at Vue Storefront, gives us the latest updates on the Shopware PWA launch.
"Shopware PWA itself is a dedicated PWA, or progressive web application, for Shopware. It's built from the ground up, on top of NuxtJS, based on the learnings we took from Vue Storefront."
"The PWA acts as the frontend for Shopware, which is treated as a backend in this approach. Basically it allows you also to have multiple sales channels, with PWA frontends, on a single Shopware instance."
"Part of Shopware PWA is a generic solution. Things like user logic; is the user logged in, how to login user, how to keep track of him, or the session management of the cart. But next to that, there are dedicated things for Shopware and it's also prepared with Shopware in mind. Keeping everything generic can create poor performance. Since we built this specifically for Shopware we can focus on good performance with the dedicated API."
If someone is interested in working with Shopware PWA, what technologies should they have a grasp of to be well prepared?
If you are interested in reading more about Shopware PWA we recommend the full interview with Patryk down below.
Delivering quality and reliable software
One of the more popular talks is a subject we do not here often about at Shopware Community Days: testing. Ramona Schwering and Jan Philipp Pietrzyk showed us what is involved with testing a product like Shopware 6.
Ramona tells us about this fascinating subject:
"We use some different types of test-automation. Some tests which you can compare to a unit test, although they have a bit more context than a normal unit test will have. We call them service tests.
Then we have integration tests, which test the components in a more systematic way. And the end-to-end tests, which are more workflow-based.
We run Unit tests and Service tests on every pull request created so that we can ensure that we don't introduce regressions. Next to that, we run integration- and end-to-end tests in a basic test case set."
"The reason I wanted to talk about testing at the Shopware Community Days is because testing is a subject that many people ask me about, how I tackle it. ‘Which test should I write, when should I write tests, when is overkill and when is too little?' My main goal is to take away the fear of tests.
So that you are not worried about the effort and the challenges you might face when doing testing, especially end-to-end tests. Read the full interview with Ramona, about her role in Quality Assurance, and how Shopware improves testing every day down below.
Growing our community
As Shopware gains more traction outside of Germany and attracts high profile clients, we see our community grow. Something we are very grateful for. And now with the new Slack channel it will be easier to meet these new faces in our group.
One of those new people in the community is Fabian Blechschmidt.
Fabian is Co-founder of MageOne, and Co-owner and developer at winkelwagen.de and talks at the Shopware Community Day about "Shopware 6 for Magento developers"
How did you get started with Shopware?
"After deciding not to go into Magento 2 as a Magento developer, the question was, what then? Since I already knew Shopware as a company, the German community is pretty well established, and the software works well for the German market it seemed the right fit. Especially since most of my clients operate in Germany."
"I have no clue if Shopware fixes all my problems, and if I complain, whether they will react to that or not, but it feels like Shopware is a company that listens to me, and tries to help me solve the challenges I face. In the Magento community, we wouldn't even consider a problem being addressed by Magento. I really need to get used to that, to not do unnecessary work because Shopware is already taking care of something. I'm really looking forward to that."
What were the best resources for you, when you started to learn about Shopware 6?
"It was definitely the documentation being done properly, which was totally unexpected for me. Unfortunately, I haven’t found much other information online so far. Most discussions seem to happen on Slack (formerly Gitter). That' s something I hope we can change!"
Fabian talks more extensively about his journey into Shopware 6 in his full interview.
Check out all of the interviews!
Next year we hope to welcome you all again in person at the Shopware Community Day 2021. Until then make sure to read the interviews and watch the talk recordings back on YouTube or our SCD recap page. And whenever you are looking for a community to talk to, you can find us on Slack!
Click on the title to read the full interview:
Event Manager at Shopware
So, you're suffering from post-Shopware Community Day depression?
Yes, always! Leading up to the event It's very stressful and you're so pumped, and then, after it's all over, you just wonder what you're going to do for the next few weeks or months. I kind of need a week to get back into daily business.
We basically planned a very normal community day for 2020 in Duisburg, in the Landschaftspark park, as we did in 2018 and 2019. It was in February, when the whole situation turned and we had to look at what was happening in the world. We were very unsure about the whole situation. I think it was mid-March when the local government finally said events up to that size were prohibited until further notice.
I think there was a week before Shopware went into full remote. We had to cancel all existing contracts with the location, and contractors, and also exhibitors of course. But everyone was very understanding of the situation. The week of the cancellation was quite hard because we didn't know what to do from that point. Do we just cancel the Shopware Community Day completely for 2020? That wasn't an option for us. We are celebrating 10 years of Shopware Community Day, and 20 years of Shopware. We had to do something!
We had to evaluate the different solutions out there. From webinar tools to Digital Event Platforms. The topic of live streaming came up very early in the conversation. And we looked into several solutions for that.
We decided to go with a very basic live stream that we had to produce completely on our own. We planned what we wanted to show in the live stream and what we would need for that, such as a stage. We decided to film it at the campus in the garage we have here. When we sat down with our existing technology partners from the region, we set up a studio and that worked out really well.
We had a live moderation on both days. Heike on the first day and Niklas on the second day, who guided viewers through the program of the day and had live interviews with the speakers.
I personally, very much enjoyed both days, especially the fact that I could just sit back and watch the live stream. We didn't have to run around to get to a certain room as you normally have to at the conference. It was a relaxed conference. I think it was the first time I attended the conference where my legs didn't hurt.
And Slack worked out well for the networking. It's always a good experience to see that people lose shyness. On the internet, everyone interacts very much more openly with each other. They don't have these hurdles standing in their way of social anxiety. I also experienced that on the Slack channels. There were so many people, logging in and chatting about all kinds of stuff and also in the live chat. The Q&A tool that we had, was also very much in use. The feedback that we got was actually that the QA sessions were too short and that's good. We were unsure of whether this tool would be used to fill a five or maybe even 10 minute Q&A or not, but obviously yes.
I'm Joshua Behrens, and I work at Heptacom, a German software development company, and Shopware Partner. Most of my daily work involves connecting shops to other systems like ERP, support systems.
My first contact with Shopware was as a customer. I once bought something in an online shop and later realized when I learned the characteristics it was a Shopware shop. It was a bit later, while I was still studying which was around the time Shopware 5 was released, some friends and I started a small company. That is Heptacom today.
We started out with plugin development on demand. We delivered components used in other shops. The first complete shop was in 2018 and that was already a bigger one who we still have today as a customer. They will migrate to Shopware 6 in the near future. They have a huge infrastructure and this will take some time. At the same time, we have to wait for Shopware 6 as a product to mature. Shopware 6 makes it super easy to intervene in already existing processes, and it's easier to change things, compared to Shopware 5, but it isn't as feature-rich compared to Shopware 5. For example, the notepad- and wishlist features are currently missing.
Was this your first Shopware Community Day?
I attended my first Shopware Community Day last year. After I took part in 2019, I wondered why I hadn’t gone before. A great event.
For me, it was very easy to take in all the talks and there were no technical problems. For an online event that used to be in-person previously, it went really well. I was sorry to see the tracks reduced to one main stage because they had one video stream. That means they had to remove lots of the content they wanted to show us or, at least reduce the talks they had. And I definitely missed the same Shopware Community Day feeling like in the last years.
What were some of the highlights for you of the Shopware Community Day lineup?
In my opinion, one presentation that really stood out was the ‘Matter of trust’ by Ramona Schwering and Phillip Pietrzyk. I guess it was one of the first talks they had about testing. It gives an inside view of how they handle testing. We didn't know much about the testing philosophy behind Shopware. So it showed us another perspective of looking at it.
I have created pull requests to the Shopware core before so I’ve already had contact with their test team. The contact was because of code where I changed the behavior of a feature in an existing point. There was an existing test and I amended that test.
Another one that I’ve kept in my mind is the talk by Aaron Schaarschmidt. It was called ‘It tastes better with cream’ because it basically has nothing to do with cream or anything like that, but it was a bait title and I remembered that, it was a good talk.
Furthermore, Dominic Klein’s talk about the Store API was very informative. I compared the given information to some of the use cases I already had worked on with the Storefront API, which is the predecessors of the presented API. By comparing the two options, I found out that it is now easier to get your own end points into that API. Despite some new restrictions, the Store API is a good solution.
This year much of the socializing of the Shopware Community Days happened on the Shopware Community Slack. Have you been active there as well?
Yes, I was already active there for a bit, before the community day. And during the event, I had contact with other attendees on the Slack channel. I also had the chance to contact Shopware directly and that was really great.
At a normal event you stay in the group up with your people, and that reduces the people you come into contact with. Although personally I do not do that. I walk around the event in person, you just see some groups of people and maybe see by their shirts where they come from ‘Oh, I know this Shopware developer’, and you see some other people around who have the same shirt. In the Slack channel, they all have the Shopware icons so I can identify those. And some attendees also have a funny description that explains what they do.
But it is a bit more difficult to see if I met them before. Did I shake hands with them? Is this the same person?
What product releases are you most excited about?
I’ve already tried the app system, before the community day, because we are developing products that are for connecting Shopware well with other systems. It is interesting to see the limitations of the app system. Of course, it is more limited than Open Source Shopware since it's a SaaS.
But it can still do a good job at, for example, sending you notifications when something changes. So we might plug an API on to that when something changes, and that is what we need. The authentication thing is still a bit messy, but all in all, I like the app system, because it works for my use cases.
Some people did seem confused by the limitations. Such as creating a custom CMS element. I think it's an easy mistake to make that the app system will work similarly to plugins.but it is limited. But many things can still be accomplished easily with the apps. That's the reason for their existence.
CEO and cofounder of Shopware
SCD Keynote Speaker
I have been CEO and shareholder at Shopware for 20 years now. Originally it was founded back in 2000. A completely different time, in comparison to now. For 20 years my brother and I have worked with a lot of passion and a lot of emotion. I would say I'm a combination of nerd and programmer, which is quite interesting. So the very first versions of Shopware came from me, but, nowadays, to be honest, I'm not allowed to write code anymore.
I started out doing programming as well as going to school. I was only doing it part-time in 2004. And so, at the beginning in our hometown, Schöppingen, you can imagine there were not very many people that knew about computers, websites, about programming and so on. It was the case back in 2000 that neighbors, family and friends asked me if I could create a website for them or, or if my brother could add a logo or catalogue.
Then we received the very first inquiry from a bigger company that asked us to create a webpage. They asked me if I wanted to send an invoice, which meant I would need to have a business, or if I wanted them to employ me for. It didn't take me very long to make the decision back then to found a company. Throughout the first years, being in school we did a little bit of everything. Around 2003/ 2004, when we got our first ecommerce project, we started to focus on the business. We did some research into the solutions available, but what we found did not meet our requirements regarding design, user-experience, and the quality of code. That was our first step towards having something as a product. Then roughly two years later we launched Shopware as a product.
Can you remember the first customer on Shopware of which you were amazed such a company would choose Shopware as their platform?
It was Arktis.de, a German retailer distributing Apple products like iPhones and Macintosh. They were one of our first customers, and it was interesting to have such a big project early on. We learned a lot about scalability for instance. Most shops had 5 or 10 orders per day, ACTIS was doing 100. This improved Shopware as a product early on.
And they remain a customer to this day, having used Shopware for 15 years now, it makes us very proud.
Looking at Shopware 6 today, can you identify the decisive moments over the last 20 years that led the company to build Shopware 6, into what it is today? The most important development was in 2015, I would say that was the year when Shopware 5 was released. It had the same code base since Shopware 3. There was further development and refactoring, but, I had the feeling along with some colleagues of mine, that it was not enough to do a slow refactoring of the different components of Shopware 5. We had to make a really hard decision, to write everything from scratch.
Otherwise, it would have meant bigger breaking changes in every release. Every change to the frontend or API part would require a big update and introducing breaks. And that reflects badly on the entire product.We also had architecture changes because of the older code base that came originally from me, and a lot of new developers that started working for us or with us, who brought in new ideas.
I believe it was the right decision to start with an established framework, like Symfony from the PHP side, because that speeds everything up. We don't have to invest time in things that have already been developed a thousand times out there and we can focus more on the ecommerce functionality and the core competencies of Shopware.
How did going Open Source play into this?
For company development, that was the most important decision. In 2010 we only had commercial licenses for Shopware, we had roughly 2- to 300 customers back then.. And then in 2010, my brother and I talked about the further development of Shopware and what we could do to reach a big audience and beat the drum a little bit more. Then we made the decision to open source Shopware and that had quite an impact on our development. Six months later we had more than 2000 customers and growing rapidly. And we had merchants of all sizes, smaller merchants on the Community version, and upper SMB and Enterprise clients on our Enterprise version. Without that decision to go Open Source we wouldn't have had our Shopware office, and over 200 colleagues in the company. That was from a business perspective, the most important decision. We spoke about the most defining moments, for the product, for the company. And for you, you went from being a developer to CEO. That's that's quite a step that not a lot of developers make in general.
What was that journey like for you? What were some of the defining moments that you faced?
Around 2011 I had the feeling that I needed to focus more on the business. Before for half of the day I was, programming things for Shopware and the other half I was thinking about the strategy and writing marketing content or doing everything that was needed. My feeling was, if you wanted to scale further, if we wanted to grow, then it was necessary that I focus more on the business development. I think it's necessary to step back a little bit to also allow other developers to leave a footprint in the product and to realize their own ideas. That goes for me as well as my brother, he is a designer originally. It was quite an important step when he said, ‘Ok, you can, create your designs. I'm very happy with the results, and I'll just give my 50 cents to every design that reaches me’. It’s exactly the same situation for me. Now it is quite important as a team to further develop our own ideas and also to shift responsibility. It's necessary that a CEO gets out of the operational business and things like writing code.
What were some of your favourite highlights from the Shopware Community Day?
We had many more talks in English this year and that's something that I really appreciate because it’s also important for the further development of the international community. What I also really enjoyed were the talks from our Shopware women, not just the men. That’s a good development. It's also important for the whole industry to make a step forward there.
Director Product for Cloud Services
I'm product director, for the area of Cloud and Services at Shopware. I started in March of last year around the time Shopware 6 was ready to launch and the plans were already there to go into the cloud. Previously I have worked for 10 years at another SaaS platform offering cloud-based eCommerce solutions for smaller merchants so it was a good fit with what Shopware was aiming to do.
When building Shopware 6, it was always meant to also be a cloud solution. So when we decided to launch Shopware Cloud there was no need to rebuild anything.
While Shopware 6 was being built we already had something called "playgrounds", which offered a Shopware 6 sandbox to developers. These were hosted on AWS as cloud solutions much like Shopware Cloud is today. This means we already had experience with AWS, as well as a solution that could run in the cloud. The next step was to launch the demo shops used to show Shopware 6 to the world., which were like a further development of the AWS infrastructure. We launched in September of 2019. This year was the third evolution of the SaaS infrastructure. There were a lot of things done to perfect the infrastructure for this multi-tenant solution of Shopware 6 on AWS. I would say that is not just the software that runs on AWS servers, it’s a real cloud-native product now.
The reason we choose a multi-tenant approach over single-tenant for example depended wholly on the target group we as Shopware are aiming at. Shopware decided to open up to the lower segment of the market at that point because we were more into the enterprise and mid-market webshops sector before. I highlighted this in my Shopware Community Day talk. I described that there was something missing at the lower segment if we want to have the whole growth story of merchants, which is important to Shopware. A multi-tenant solution where you use the same application and a lot of infrastructure for a lot of shops means that you can run the whole system more cheaply.
I think an important point is that this multi-tenant solution really makes sense for small clients and the bigger you get, the more possibilities you need. The bigger a webshop gets the more important it is to be a more single-tenant, I would say, but that is a lot more expensive. Choosing multi-tenant is the first step. I do want to stress that the cloud isn't just for smaller merchants and single-tenant or on-premise for Enterprise. The goal is to offer the right solution to any size of merchant, based on their needs.
I would say in the segment of smaller webshops, you will have like 90 % running on the cloud and in the segment with the biggest and most complex webshops, it will be 50 % at long term or something, but it will always be on-premise because it's a lot more flexible.
One of the strongest points of Shopware is its extensive ecosystem. Plugins vendors, agencies, and so on. What are the opportunities for them when it comes to the cloud?
We know that the ecosystem and all the developers around Shopware are the biggest assets Shopware has. That is really important to us. It was from the beginning, something which we had in mind when we started to think about how to do the cloud and how we could involve the ecosystem in a SaaS solution. There are a lot of challenges when doing so, because we, as a SaaS provider, are responsible for running the system, we are responsible for the performance, the security and everything else touching the solution. We cannot let everybody on the file system and install plugins into it. Especially not in a multi-tenant environment where you change one thing and the application runs for all the shops.
It was quite clear that we could not run with the same plug-in system we had for the on-premise solution. Because it is so important for us to take the ecosystem with us, we developed a new extension system, which is called the App system. This system doesn't operate on the file level but on the communication level. An app is an external service communicating with Shopware, and we do it with webhooks and API. And for cases where you can't directly touch the admin interface, we provide solutions, like an I-frame solution, where you can show your settings, and we provide a mechanism to add UI elements to the interface for example. From the beginning, we developed a new extension system to take the ecosystem with us into this new world.
A very important point is flexibility. We always want the merchant to have an easy way to migrate from the Cloud solution to on-premise. This way, if you need more flexibility than our standard solutions offer, you can base your on-premise shop on what you built in the cloud. When it comes to the extensions you're using the App system was built to also run an on-prem installation which means there will be an easy way to migrate your entire solution. You can take all the apps you have used there with you.
We think from a vision perspective, maybe the Plugin system will be less important in the future. The App system will be more important because it runs in both worlds. As we are going to develop it further, there will be less and less you cannot do with the App system.
What does the roadmap look like for Shopware Cloud?
I think one of the most important things is the app store because now it's possible to develop apps and the next step is that we have these app stores inside the Shopware admin, where you can directly buy themes and apps with just one click.
What is your advice to agencies or developers who want to prepare for developing with the App system?
I think the main point is that in one way it is easier because you don't have to stick to a lot of the things we require for the current plugins right now, because they live inside Shopware, inside the file system. Then you are totally free to use any programming language you want and to develop the way you want to. On the other hand, you have to be like a SaaS provider as well, because it has to run on a server and it has to be available all the time.
To help our developers, we are working together with Platform SH to build a template to make developing and setting up the infrastructure easy.
That will make it easy to start to be like a SaaS provider because Platform SH is managing that. You can just start right away to run your application on Platform SH.
What were some of the key highlights that you wanted to give to the listeners one when you gave your talk?
The key message is that you can really grow with Shopware. It allows you to start with an idea and a small budget. No knowledge is required on how to build a webshop yourself. It offers a really easy way to start from the beginning. And from there you can grow your business, have changes over time, and you will not run into any limitations. You start with the Cloud Solution and grow into a higher tier solution, on-prem. There is no need to change the platform you use. I think these are the key messages we have, that you can roll with Shopware and you can start from the very early beginning of your business.
What were some of the talks that inspired you on the Shopware Community Day?
For me, I really enjoyed the keynote of Stefan on the first day and Josua on the second day. I liked the overview of the idea process. And I enjoyed the talks about PWA and the Shopware Market solution.
Core Developer at Shopware
SCD Speaker "The Shopware 6 app system"
I've been working at Shopware for the past three and a half years. I started out as an apprentice there. During my time at Shopware I've developed some distributed systems and worked on getting Shopware 6 launched. And for the past 6 months, I've been working on the Shopware Cloud solution.
I believe developers should be enthusiastic about Shopware Cloud because it allows you to focus on developing instead of caring about stuff like Apache Server configuration, which for me, is the bane of my existence. You fill out a form to spin up a new Shopware Cloud instance, you get a shop, and then you can interact with it over the API. Which, at least, in my opinion, is, a way cooler thing to do than to first find a hosting solution, install all the different web servers, database versions, download the application, and then set it up.
I do think there will be some impactful changes for developers. When it comes to creating Apps for Shopware cloud, developers can do this in any language they want, and host it where they want. PHP would be a good choice of course, and I think that most developers who are working with Shopware 6 right now would be able to write a Shopware App system application just like any other web application. Basically the only thing that your app has to do is pass JSON and then perform your business logic on that data. That is quite easy to implement in most languages and especially PHP.
The app itself, the actual files you write for Shopware, those are just an interface definition. It describes what events you want to be subscribed to, and what changes you want to do to the UI of the shop. And it also contains the URLs of the application that listens to those subscribed events. The app is basically two parts. The aforementioned interface description, what we call manifesting XML, the files you actually upload and share when a customer buys your app. And the rest of it is the back end. This is just an application that provides HTTP endpoints that listen to observed events. It communicates with Shopware itself via APIs over HTTPS.
What I wanted to show during my talk at the Shopware Community Day, is that even though it's quite different from the way Shopware was extended previously with plugins, it will make a lot of things easier. It provides a cleaner interface between the extension and the core of Shopware itself. I think what is also pretty neat is that you can now choose your own language you want to develop in, which may be leaves you with more possibilities to extend current systems with an interface to the App system.
We hope to see many more developers. Not knowing PHP or Symfony is no longer an entry barrier.
I think it fits well as a cornerstone for the new Shopware PWA. You can extend the PWA through the app system. I like the idea of distributing the computation so to say. You've got a very, user-focused piece of software right on the user devices with the PWA. And a very ecommerce system focused, piece of software on the server. Either hosted yourself or in the cloud with a Shopware core, maybe even completely headless. You've got your Shopware Apps that can really focus on interacting with third party systems.
What were some of the highlights for you during Shopware Community Day?
I spent most of the first day of the community day just listening to my colleagues talk in the background. The entire Cloud Team was waiting and monitoring the cloud application, for the moment it would be opened up to the public. On the second day, I was a bit busier with actually being there and having my Q&A session. Luckily I still managed to listen to some talks, for example, the one about testing with Jan Philip and Ramona. That one I liked quite a lot because I pretty much agree with them that testing is important.
Most of the product announcements were not new to me, I know about them already. But what is pretty cool is that we've got lots of customers that have good things to say about us as a product, and as a company. That was great to hear. And what I was excited about is the custom Docker setup Dasistweb created which runs well on Mac. That was very much a pain point for a lot of us, that we tried to figure out how to do this.
I also like the new workflow mechanism, because this really speaks to me as well as a programmer and logic nerd, that you can now build kinds of workflows to automate different tasks.
And Shopware Community Days online gave certain benefits. Like now we know that lots of international guests and in general, people that couldn't be there in person and would have been at the physical event, are interested in our stream and watch it. I think that's pretty great that we can deliver the event to the people, instead of them having to come to us. We even had several viewers in Pakistan, it was quite high up even in the ranking.
Technical Specialist at Shopware and SCD Speaker "Introducing Store API"
How did you get started with Shopware?
I have been doing IT tech and web development for the biggest part of my life I’d say. I graduated in Computer Sciences and worked in web application development afterward. So database design, information architecture. And then I started working at Shopware as a core developer on Shopware 5.
Not long after that, I transitioned to a new project called 'Shopware Next', which was also known as 'Shopware X' and 'Shopware Platform', which ended up being called 'Shopware 6' unsurprisingly.
After that, I got more involved with end projects where we realize shops for clients. And some of the learnings i picked up there made it back into Shopware 6. I make sure I keep this deep and technical understanding of Shopware 6, to bridge the gap between end projects and the core product.
Your current position is Technical Specialist, which is its own team in Shopware.
That’s right, for the last two years, we have been building this team which is responsible for understanding market requirements by working closely together with partners and end clients.
Next to that, we collaborate intensively with the product development team to ensure more understanding of the market, and more maturity of solutions in the final product.
And that is essentially what I'm doing right now, which crosses paths with many other departments within Shopware, and outside of it. I work on helping out on sales pitches for new clients. And give talks, podcasts, and write blog articles for our community.
Shopware 6 and Open Source
On that community; the decision to go Open Source was made quite a few years ago even before Shopware 5, Shopware 6 seems to be the culmination of that new vision on software development though. It uses Open Source libraries, embraces developer contributions from the outside, contributing back to the ecosystem.
Yes, I would say we believe firmly in Open Source and the drive and innovation power that comes from outside contributions. We see ourselves as giving strategic direction to the product that, we think, is a good solution for the market.
At the same time, we believe that there is a massive contribution that the Open Source space can make, and help us improve the product which pays off for everyone involved.
Taking this Open Source approach, which doesn't only refer to disclosing source code, but also involving other people and being open to contributions and discussions regarding the code, and building a whole ecosystem around this, is what really matters and drives us.
Lets talk about your session "Introducing Store API" at the Shopware Community Day
The key takeaway I wanted to convey in my talk "Introducing Store API" at the Shopware Community Day is the understanding that the shop system, Shopware 6, and the frontend interface are not one stack.
When you see a platform as one monolithic stack it will restrict the freedom in development. While it might seem convenient to have the opportunity to call your MySQL database even from the template files, for the sake of creating a robust application it is something that you certainly do not want to allow. You want to introduce a level of abstraction in order to craft good software, which allows for better extension for example, which gives developers a broader set of tools to work with and build on.
I wanted to convey the understanding of having a functional space in the software, and these functions and processes are encapsulated in API endpoints which should be the way external systems, such as a decoupled PWA frontend, interact with your software.
And only when you cover a hundred percent of the functionalities in the software with API endpoints do you allow for other software to fully integrate with your core system, which would be Shopware 6 in this case.
And then on the less abstract side, I wanted to show of course how this would work practically, translating it into actual written code.
An API first approach
Shopware 6 has been built, from the ground up, to be API-first. Does this come directly from having an Open Source product, and listening to feedback from end clients?
API first is something that allows you to reconsider a lot of things about your software in terms of what you're trying to solve how you're trying to solve them.
A lot of projects, I think, tend to be very pragmatic about their approach in solving specific problems, and that leads to them having the kind of solutions that fit a very small purpose, but as a whole, it tends to lead to code and functionality being very interwoven with each other.
Whereas when you're really designing your software to be API driven it stays a lot cleaner. This means to be very clear on what your interfaces are, what your processes are, and what your data looks like. And when you put an extension mechanism on top of that, it makes it more powerful.
And I believe that people out there in the Open Source community who understand these concepts very well and can contribute their experience, will in return benefit from well-written software. And in the end, that will again be also of benefit for the customers that use Shopware.
Shopware 6 initially came with CRUD APIs that allow you to create, edit, and delete entities. Once the core team started to look at integrating PWA for Shopware 6, you identified a need for a new type of API, which turned out to be the Store API. Can you elaborate on how that evolved and what its purpose is?
I believe CRUD APIs are a commodity by now. Every system should have some kind of CRUD API to allow simple data operations, without having to work directly in the underlying database of that system. It offers better resilience, consistency, and reliability, and so on.
However, introducing the Store API posed a whole new set of challenges. We aimed to provide a consistent API interface that allows other systems to interact with Shopware, not in a data- or entity-driven way, but in a process-driven way.
We started to develop a project to that end, called the Sales Channel API. But during development, we discovered that we had a fundamental misconception about the way it should be done. We quickly uncovered some of the bigger drawbacks that this approach brings. The biggest being we were defining the same business logic twice on the platform. On the one hand, we have the current frontend, with controllers, that render the frontend using different parts of the application calling lower-level services.
On the other hand, we were trying to reproduce similar behavior for the Sales Channel API. Which ended up putting functionalities inside the Sales Channel API which then would also need to be implemented elsewhere to be available for the current frontend.
Luckily we identified this issue early on. And the result of that learning is the Store API.The Store API encapsulates bigger architectural decisions where we decided that these lower-level services used by the Sales Channel API and controllers have to be API endpoints themselves. And this worked well without much effort, just by exposing them via API routes.
In several cases, we had to make decisions that lead to refactoring interfaces to work better with data transfer objects for example. All of this led us to be able to expose all of that lower-level business functionality which we composed into the current Storefront and the Store API endpoint.
The Store API for more than just frontends
The Store API is absolutely not just for PWA frontends. Although it powers Shopware PWA we focussed on not tailoring it specifically to that. This would go against the idea behind having the Store API.
What we want to do is decouple systems from one another, not introduce more tight coupling with an API in the middle - what would be the benefit?
What we're trying to do is have a solution that is as generic as possible that other applications can use as well. Whether it be a PWA or using a PHP-based static site generator as your frontend for example.
If you are integrating Shopware with something such as Adobe Experience Manager as a CMS, displaying Shopware products on the AEM frontend you would be fully capable of doing so. The same goes for having a frontend written as a Swift application for iOS, which can use the Store API to authenticate users in the app and display Shopping Experiences.
The Store API liberates developers from a specific platform and gives them the freedom to choose the solution they like best.
- Lead developer at Vue Storefront on the Shopware PWA team
- SCD Speaker "Shopware PWA for developers"
- Twitter: @tomczykpatryk
I’ve been working on the Shopware PWA since the very beginning of the project. Before that I was working on Vue Storefront for one and a half years when I got the offer to lead the Shopware PWA team. The team is a collaboration between Vue Storefront and Shopware, working together on a daily basis to build the product.
Shopware PWA itself is a dedicated PWA, or progressive web application, for Shopware. It's built from the ground up, on top of NuxtJS, based on the learnings we took from Vue Storefront. The PWA acts as the frontend for Shopware, which is treated as a backend in this approach. Basically it allows you also to have multiple sales channels, with PWA frontends, on a single Shopware instance.
The main difference between Vue Storefront, and Shopware PWA is the close integration with the CMS, or Shopping Experiences, in Shopware. As well as with the plugin system from Shopware which it integrates with.
Part of Shopware PWA is a generic solution, the architecture is very similar to what we built for Vue Storefront Next. Things like user logic; is the user logged in, how to login user, how to keep track of him, or the session management of the cart.
But next to that, there are dedicated things for Shopware and it's also prepared with Shopware in mind. Keeping everything generic can create poor performance. Since we built this specifically for Shopware we can focus on good performance with the dedicated API.
If someone is interested in working with Shopware PWA, what technologies should they have a grasp of to be well prepared?
But it's not mandatory, you can catch up with this at a later stage. And it would be nice to read something about NodeS itself, to know where you can later deploy and host your PWA applications as well. You need separate hosting for your Shopware PWA application because currently Shopware server doesn’t require you to have Node JS installed. Of course if you install it on the same server you can host it there. I would say it's not recommended to have it this way. It's better to have it on a separate server.
What are some of the best use cases for Shopware PWA?
I would say it can be for everyone, but not everyone will have the same use case. If you have some development skills or you have a team which is doing development for you, then it makes a lot of sense for you because you get a very fast and fully customizable product. If you just have a very small shop and you don't have any development team it's maybe too much effort to accomplish that. You want to have a good, working backend and frontend application, it's not only one application.
Your talk during Shopware Community Day was all about Shopware PWA. What were some of the key takeaways that you wanted to convey to the listeners?
We want them to know that we’re here for them. We are waiting for their feedback on their first implementations. We are happy to answer their questions as well. We’re happy to provide the help they need to start with Shopware PWA and to make this product better for them. So if they start playing with it and something does not meet their expectations, they should just let us know and we can work on the solution with them.
The best way is to create an issue on Github. And it’s always good to try Shopware PWA chanel on the Vue Storefront Slack, because I believe that most of the community is there. They ask questions, they talk with each other as well. I, This is the place where most of the people involved with Shopware, PWA and development are.
Did you enjoy Shopware Community Day as an online conference?
It was very comfortable to watch as you're sitting in your own home, but then you also can miss a few talks because you're also working at the same time. I was distracted by daily events. The event was very well organized. The schedule was precisely put in there so everywhere everything went very well.
Quality Assurance at Shopware, SCD Speaker "A matter of trust – test"
I started out at Shopware almost five years ago. In the Quality Assurance for Product Development.That means I test the core, a bit of the Shopware services and plugins, all those kinds of things.To be more specific, I have responsibility for the end-to-end testing, and for the tests in the build pipelines connected to the project. I work together with the team to write all the tests for that. And I head up the testers here at Product Development.
The main importance of testing is of course that we want to deliver the best quality we are able to. We have the responsibility to all the customers working with Shopware, and we want them to be successful with our solution. With automated and manual testing we ensure quality and ensure that we have no defects. At least up to a high level of certainty - we try to get as close to 100 % as we can.
We use some different types of test-automation, of course. Some tests which you can compare to a unit test, as we highlighted in our talk during the Shopware Community Day. They do have a bit more context than a normal unit test will have. We call them service tests.
Then we have integration tests, which test the components in a more systematic way. And the end-to-end tests, which are more workflow-based. We run Unit tests and Service tests on every pull request created so that we can ensure that we don't introduce regressions and to be notified if anything breaks the application. Next to that, we run integration- and end-to-end tests in a basic test case set, this covers the most important functionalities and the most important workflows which are also executed on each PR. Full test case runs with more test cases are executed on a daily basis during the night because they take several hours to run.
After the last Boost Day we ran our tests as well, but locally and manually. We use Gitlab internally. that's a little different. For the next Boost Days we hope to integrate some of our pipelines directly. Now one of my colleagues executes all the tests and does some corrections if necessary. Little things can be fixed by testers as well. Some of our testers can code actually. Little bug fixes or snippet changes are done by the testers.In this case as well, you could say that the creation of a ticket would last longer than just fixing it, but the bigger things we leave to the developers who are in charge of it.
The reason I wanted to talk about testing at the Shopware Community Days is because testing is a subject that many people ask me about, how I tackle it. ‘Which test should I write, when should I write tests, when is overkill and when is too little?' My main goal is to take away the fear of tests. So that you are not worried about the effort and the challenges you might face when doing testing, especially end-to-end tests. Worries like flakiness in the results, and the maintainability. I just want it to be a fun and exciting topic. And so I think it is a good opportunity to give people a starting point, how to start with tests and how to make them fun and exciting, and not as much of an obstacle as some people might think. Especially at the community day where we want to inspire trust in Shopware as a company and product.
What were some of your personal favourite talks at the Shopware Community Day?
I definitely liked the talks about theme and plugin development, as I myself like to learn more on those topics.They are a good starting point for me to maybe write on a theme or something and to understand the role of a developer better.
And there were testing related questions on the Shopware Community Slack group and chat channel. Some really important and exciting exciting questions. I was able to answer even the last questions from the Q&A session which was cut a bit short. It was a question concerning if you should write tests against production or not.
And what was the answer? Do you write against production?
I'm not that strong at unit tests at the moment.I'm still learning in this area, but they asked about security concerns so that you shouldn't do that in production, but if you're using end to end tests and don't do an operation, which would write some data in your shop, like doing some order, but just opening URLs in the frontend, might be okay. As long as you do not perform tests that make changes to your shop.
There were a lot of new product presentations at Shopware Community Day. Shopware Cloud, Shopper PWA, and the Shopware 6 road map. What is the one thing that you are most excited about?
Shopware Cloud of course. I'm quite excited to see it working in the wild, with real customers. and I'm really curious how people will be using it. And I'm looking forward to feedback on what they think of the product.
Specifically in cloud environments, you release at a faster pace, so it would be impossible for us to check all those scenarios manually, so we have to improve our testing as well. I was relieved to see that the cloud developers are writing their own tests as well. I was a reviewer in the Pull Request, but I didn't need to change lots of things. Which is quite cool because by doing it like this I see that the developers are always thinking about quality aspects.
Of course, for me as I'm writing tests for the core product I have to keep in mind that all the things we are using in our core product, are also used in the cloud. So I have to think about some extra test cases too. And implementing those in our test suits.