Highlights, Interviews und ein Blick hinter die Kulissen
In den vergangenen neun Jahren haben sich die Fans von Shopware jedes Jahr an einem Ort in Deutschland getroffen, um sich Vorträge über die neuesten Updates und Produkt-Rollouts von Shopware anzuhören.
Dieses Jahr haben wir am 18. und 19. Juni die zehnte Ausgabe des Shopware Community Day und 20 Jahre Shopware gefeiert, diesmal allerdings im Rahmen einer Online-Veranstaltung.
Per Livestream vom Shopware Community Day wurden an den beiden Tagen 34 Vorträge übertragen, die von über 3.000 Teilnehmern aus der ganzen Welt angesehen wurden – von Deutschland, Italien, den Niederlanden und Polen über Ecuador und Mauritius bis zu den Philippinen.
Wie haben die Speaker, Mitarbeiter und Besucher den Tag erlebt?
Zuerst erzählt uns Björn Meß (Event Manager bei Shopware) etwas über die diesjährigen organisatorischen Herausforderungen:
"Wir haben für 2020 im Grunde genommen einen ganz normalen Shopware Community Day im Landschaftspark Duisburg-Nord geplant, wie schon für die Jahre 2018 und 2019. Es war im Februar, als die ganze Situation begonnen hatte, sich zu drehen. Die Woche der Absage war schwierig, weil wir nicht wussten, was danach kommen würde. Würden wir den SCD 2020 komplett absagen? Das war aber eigentlich keine Option für uns. Wir feiern den 10. Shopware Community Day und 20 Jahre Shopware, wir mussten also irgendwas machen!"
"Ich persönlich habe beide Tage sehr genossen, vor allem den Umstand, dass ich mich auch mal einfach zurücklehnen und den Livestream anschauen konnte. Wir mussten nicht herumlaufen, um von Raum A zu Raum B zu gelangen wie es sonst beim SCD ist. Es war ein entspannter Tag. Ich glaube, das war das erste Mal, dass mir meine Beine nach dem SCD nicht wehtaten."
"Und Slack hat zum Networking auch klasse funktioniert. Es ist immer schön zu sehen, wenn Leute ihre Schüchternheit überwinden. Es haben sich so viele Leute dort angemeldet und sich über alle möglichen Dinge unterhalten. Auch im Live-Chat war das so. Das Q&A-Tool, das wir hatten, wurde auch viel genutzt. Wir haben tatsächlich das Feedback bekommen, das die Q&A-Sessions zu kurz waren. Das ist gut. Wir waren nicht sicher, ob das Tool genug Anklang finden würde, um einen 5- oder 10-minütiges Live-Q&A zu füllen, aber so wissen wir, dass es gut ankam!"
Das Event-Team hat in nur zwei Monaten aus der Präsenzveranstaltung ein Online-Event gemacht. Eine beeindruckende Leistung! Zusammen mit den Mitarbeitern von Shopware und örtlichen Unternehmen wurde am Hauptsitz von Shopware eine Aufnahmebühne aufgebaut und das Event von dort live gestreamt. Wenn du mehr über die Produktion des Shopware Community Days erfahren möchtest, findest du das vollständige Interview mit Björn weiter unten auf dieser Seite.
Wir sprechen mit Joshua Behrens, Partner und Entwickler bei Heptacom und Shopware Ambassador, darüber, wie er den Shopware Community Day 2020 erlebt hat:
"Dieses Jahr konnte ich ganz leicht an allen Vorträgen teilnehmen und es gab keine technischen Probleme. Für ein Online-Event, das bisher eine Präsenzveranstaltung war, lief es wirklich gut. Schade war, dass die gesamte Übertragung auf eine Hauptbühne beschränkt war, weil sie nur einen Videostream hatten. Das hatte zur Folge, dass sie viele Inhalte weglassen mussten, die sie eigentlich zeigen wollten."
Welche Vorträge gehörten für dich zu den Highlights des Shopware Community Day?
"Einer, der wirklich herausstach, war ‚Matter of trust‘ von Ramona und Phillip. Ich denke, es war einer der ersten Vorträge am Shopware Community Day über Tests. Darin geben sie einen Einblick in ihren Umgang mit Tests. Wir kennen die Testphilosophie von Shopware ja nicht. Dieser Vortrag hat uns also einen neuen Blickwinkel gezeigt."
"Außerdem habe ich die Informationen aus Dominics Vortrag über die Store-API mit einigen der Use Cases verglichen, an denen ich bereits mit der Storefront-API gearbeitet habe, also dem Vorgänger der API, die sie dort vorgestellt haben. Mich hat interessiert, ob es im Vergleich zu früher nun einfacher ist, meine eigenen Endpunkte in diese API zu integrieren. Es ist definitiv einfacher. Es gibt auch einige neue Einschränkungen, aber alles in allem ist es ein guter Tausch."
Das vollständige Interview mit Joshua über seine Meinung zu Shopware, seinen Hintergrund und mehr findest du weiter unten auf dieser Seite.
Fabian Blechschmidt hat der Shopware Community Day sowohl als Redner als auch als Konferenzteilnehmer gut gefallen:
Keynotes, Produktpräsentationen und Stimmen aus der Community
Den Auftakt an Tag 1 machte eine Keynote von Stefan Hamann, CEO und Mitgründer von Shopware. Er sprach nicht nur über das Produkt, sondern gab auch einen Einblick in die Anfänge von Shopware und erzählte, wie das Unternehmen auf über 200 Mitarbeiter angewachsen ist.
Kannst Du Dich an den ersten Kunden auf Shopware erinnern, bei dem Du beeindruckt warst, dass ein Unternehmen wie dieses Shopware als Plattform wählt?
"Das war Arktis.de, einer unserer ersten Kunden. Es war interessant, so früh ein so großes Projekt zu haben. Da haben wir zum Beispiel viel über Skalierbarkeit gelernt. Die meisten Shops hatten 5 oder 10 Bestellungen täglich, Arktis hatte 100. Das hat schon früh zur Verbesserung von Shopware beigetragen."
"Das war die Geburt von Shopware im Jahr 2004 und ungefähr zwei Jahre später kam der Release von Shopware 2. Und in Shopware 2 gab es bereits einiges, was wir heute noch haben. Die Einkaufserlebnisse zum Beispiel, das Drag-and-Drop-Prinzip, waren schon 2006 Teil des Produktes."
Kannst Du mit Blick auf Shopware 6 heute die entscheidenden Momente in den vergangenen 20 Jahren benennen, die das Unternehmen dazu geführt haben, Shopware 6 zu dem zu machen, was es heute ist?
"Ich würde sagen, die wichtigste Entwicklung gab es 2015. Das war das Jahr, in dem Shopware 5 veröffentlicht wurde. Seit Shopware 3 hatten wir denselben Basiscode verwendet. Wir mussten die sehr schwere Entscheidung treffen, für Shopware 6 alles von Grund auf neu zu schreiben."
"Ich glaube, es war die richtige Entscheidung, mit einem etablierten Framework wie Symfony auf der PHP-Seite zu beginnen, denn damit geht alles schneller. Wir müssen keine Zeit in Dinge investieren, die bereits tausendfach entwickelt wurden, und können uns mehr auf die E-Commerce-Funktionalität und die Kernkompetenzen von Shopware konzentrieren."
Das vollständige Interview mit Stefan über die Entwicklung von Shopware als Unternehmen, das Produkt und seine Rolle findest Du weiter unten auf dieser Seite.
Shopware in der Cloud
Eine weitere große Produkteinführung ist die neue Shopware Cloud, eine SaaS-Version von Shopware 6. Jörn Paulsen, Director Product für Cloud & Services, und Christian Rades, Core-Entwickler, sprachen beide über die neuste Erweiterung der Produktpalette von Shopware.
"Während der Entwicklung von Shopware 6 hatten wir bereits sogenannte ‚Playgrounds‘, die Entwicklern als Sandbox für Shopware 6 dienten. Die wurden als Cloud-Lösungen auf AWS gehostet, ähnlich wie Shopware Cloud heute. Das bedeutet, dass wir bereits Erfahrung mit AWS und auch mit einer Cloud-fähigen Lösung hatten. Der nächste Schritt war die Veröffentlichung der Demoshops, die eine Art Weiterentwicklung der AWS-Infrastruktur waren, um Shopware 6 der Welt vorzustellen. Der Launch erfolgte im September 2019. Dieses Jahr gab es die dritte Weiterentwicklung der SaaS-Infrastruktur. Wir haben einiges getan, um die Infrastruktur für diese Multi-Tenant-Lösung von Shopware 6 auf AWS zu perfektionieren. Ich würde sagen, das ist nicht mehr nur eine Software, die auf AWS-Servern läuft, sondern jetzt ein tatsächlich Cloud-natives Produkt."
"Ich denke, es gibt einige wirkungsvolle Veränderungen für Entwickler. Für Shopware Cloud können sie Apps in jeder beliebigen Sprache entwickeln und sie hosten, wo sie möchten. Die meisten Entwickler, die derzeit mit Shopware 6 arbeiten, können eine App-Systemanwendung für Shopware wie jede andere Webanwendung schreiben."
"Die eigentlichen Dateien, die man für Shopware schreibt, sind nur eine Schnittstellendefinition, die beschreibt, welche Events man abonnieren möchte und welche Änderungen man an der Shopoberfläche vornehmen möchte. Die App besteht im Wesentlichen aus zwei Teilen. Da ist zum einen die erwähnte Schnittstellenbeschreibung, die sogenannte Manifest-XML, und der Rest ist das Backend. Das ist einfach eine Anwendung mit HTTP-Endpunkten, die beobachtete Events abfragen. Sie kommuniziert mit Shopware selbst über APIs über HTTPS."
Im Interview mit Jörn erfärst Du mehr über die Features und Funktionen von Shopware Cloud, das Interview mit Christian liefert hingegen tiefere Einblicke in die Entwicklung von Apps.
Und natürlich gab es viele Beiträge zu Headless APIs und PWA.
Dominic Klein, Technical Specialist bei Shopware, spricht mit uns über die neue Store-API:
"Das Wichtigste, was ich in meinem Vortrag ‚Introducing Store API‘ beim Shopware Community Day vermitteln wollte, ist das Verständnis, dass das Shopsystem, Shopware 6, und die Frontend-Schnittstelle nicht einen Stack bilden."
"Wenn man eine Plattform als einen monolithischen Stack betrachtet, beschränkt das die Entwicklungsfreiheit. Die Möglichkeit, die MySQL-Datenbank sogar in den Template-Dateien aufzurufen, mag zwar bequem erscheinen, aber wenn man eine stabile Anwendung entwickeln will, sollte man das auf keinen Fall zulassen. Für den Aufbau einer guten Software sollte man eine Abstraktionsebene einführen, die zum Beispiel eine bessere Erweiterung erlaubt, sodass Entwickler mit einer größeren Auswahl an Tools arbeiten und auf diesen aufbauen können."
"Ich wollte die Vorstellung eines Funktionsraums innerhalb der Software vermitteln, dessen Funktionen und Prozesse in geschlossenen API-Endpunkten vorliegen. Auf diese Art sollten externe Systeme wie entkoppelte PWA-Frontends mit der jeweiligen Software interagieren. Und erst wenn man die Funktionen in der Software zu 100 Prozent mit API-Endpunkten abdeckt, erlaubt man einer anderen Software, wie in diesem Fall Shopware 6, die volle Integration in das eigene Kernsystem."
In seinem vollständigen Interview weiter unten auf dieser Seite erzählt Dominic mehr über die Store-API und seine Rolle bei Shopware.
Patryk Tomczyk, leitender Entwickler beim Shopware-PWA-Projekt bei Vue Storefront, spricht über die Neuigkeiten rund um den Launch der Shopware-PWA:
"Die Shopware-PWA ist eine PWA bzw. Progressive Web App speziell für Shopware. Sie wurde auf Basis der Erfahrungen, die wir mit Vue Storefront gemacht haben, von Grund auf mit Nuxt.js aufgebaut."
"Die PWA fungiert als Frontend für Shopware, das bei diesem Ansatz als Backend behandelt wird. Außerdem erlaubt sie auch mehrere Verkaufskanäle mit PWA-Frontends in einer Shopware-Instanz."
"Aber darüber hinaus gibt es spezifische Elemente für Shopware und sie auch wurde im Hinblick auf Shopware entwickelt. Eine rein generische Programmierung kann die Performance beeinträchtigen. Da wir diese PWA speziell für Shopware entwickelt haben, können wir sie auf eine gute Performance mit der spezifischen API ausrichten."
Welche Technologien sollte man kennen, um gut mit der Shopware-PWA arbeiten zu können?
Wenn Du mehr über die Shopware-PWA erfahren möchtest, empfehlen wir das vollständige Interview mit Patryk weiter unten auf dieser Seite.
Hochwertige und zuverlässige Software bereitstellen
Bei einem der besonders beliebten Vorträge ging es um das Testen, ein Thema, über das beim Shopware Community Day nicht so häufig gesprochen wird. Ramona Schwering und Jan Philipp Pietrzyk haben uns gezeigt, worauf es beim Testen eines Produktes wie Shopware 6 ankommt. Über dieses spannende Thema haben wir mit Ramona gesprochen.
Ramona tells us about this fascinating subject:
"Wir verwenden eine Reihe unterschiedlicher Testautomatisierungen. Einige Tests sind mit einem Unit-Test vergleichbar, haben jedoch etwas mehr Kontext als ein normaler Komponententest. Wir nennen sie Servicetests.
Dann haben wir Integrationstests, bei denen die Komponenten systematischer getestet werden, und die End-to-End-Tests, die stärker Workflow-basiert sind.
Wir führen Komponententests und Servicetests für jeden Pull Request durch, um Regressionen zu vermeiden. Anschließend führen wir Integrations- und End-to-End-Tests in einem einfachen Testfall-Setup durch."
"Ich wollte beim Shopware Community Day über das Testen sprechen, weil ich immer wieder danach gefragt werde: ‚Welche Tests muss ich schreiben, wann muss ich Tests schreiben, wann ist es übertrieben und wann ist es zu wenig?‘ Ich will den Leuten vor allem die Angst vor Tests nehmen und Bedenken in Bezug auf den Aufwand und die Probleme ausräumen, denen man beim Testen begegnen kann, insbesondere bei End-to-End-Tests."
Das vollständige Interview mit Ramona über ihre Rolle in der Qualitätssicherung und darüber, wie Shopware täglich die Tests verbessert, findest du weiter unten auf dieser Seite.
Die Community wächst
Da Shopware zunehmend außerhalb von Deutschland Fuß fasst und angesehene Kunden gewinnt, wächst auch unsere Community. Dafür sind wir sehr dankbar. Und der neue Slack-Channel macht es jetzt einfacher, diese neuen Gesichter in unserer Gemeinschaft zu begrüßen.
Eines der neuen Mitglieder unserer Community ist Fabian Blechschmidt. Fabian ist Mitgründer von MageOne und Miteigentümer und Entwickler bei winkelwagen.de.
Fabian hat beim Shopware Community Day über „Shopware 6 for Magento developers“ gesprochen.
Wie bist Du dazu gekommen, mit Shopware zu arbeiten?
"Nachdem ich beschlossen hatte, als Magento-Entwickler nicht zu Magento 2 zu wechseln, war die Frage: Was nun? Da ich Shopware als Unternehmen bereits kannte, die deutsche Community gut etabliert ist und die Software am deutschen Markt gut funktioniert, schien das die passende Wahl zu sein. Vor allem, da die meisten meiner Kunden in Deutschland tätig sind."
"Ich habe keine Ahnung, ob Shopware alle meine Probleme lösen kann und ob sie reagieren werden oder nicht, wenn ich etwas beanstande. Aber ich habe den Eindruck, dass Shopware ein Unternehmen ist, das mir zuhört und versucht, mir bei der Lösung meiner Probleme zu helfen. In der Magento-Community würde es uns nicht einmal in den Sinn kommen, dass sich Magento mit einem Problem befassen könnte. Daran muss ich mich wirklich noch gewöhnen, damit ich keine unnötige Arbeit investiere, weil sich Shopware bereits um eine Sache kümmert. Darauf freue ich mich sehr."
Als Du begonnen hast, Dich mit Shopware 6 zu befassen, was waren da für Dich die hilfreichsten Ressourcen?
"Das war definitiv die ordentliche Dokumentation, mit der ich absolut nicht gerechnet hatte. Leider habe ich bisher online kaum weitere Informationen gefunden. Die meisten Diskussionen scheinen auf Slack (früher Gitter) stattzufinden. Ich hoffe, das können wir ändern!"
In seinem vollständigen Interview (auf englisch) erzählt Fabian ausführlicher über seinen Weg zu Shopware 6.
Wirf einen Blick auf alle Interviews!
Wir hoffen, nächstes Jahr zum Shopware Community Day 2021 wieder alle persönlich begrüßen zu können. Bis dahin stehen Dir hier die Interviews und auf YouTube und der SCD Recap Seite die Aufzeichnungen der Vorträge zur Verfügung. Und wenn Du Dich mit der Community austauschen möchtest, findest Du uns auf Slack!
Klick auf den Titel, um das komplette Interview zu sehen (die meisten Interviews sind nur auf englisch verfügbar):
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.