Shopware Version 6: What does API-First Mean to Merchants?

James:

Hello and welcome to the Re:platform podcast. Happy new year to everybody. This is the first podcast of 2020, moving into an exciting new year after a lazy few weeks for both me and Paul sitting back eating far too much and drinking. We’re ready to roll with some cracking new episodes. There’s a lot of exciting stuff lined up for you in 2020 and in our latest episode we’re getting under the hood of the new Shopware platform version 6, which was launched in 2019. We’re happy to be joined today by Dominic Klein who’s a technical specialist with Shopware. Welcome Dominic, did you have a good Christmas?

Dominic:

Absolutely. Yeah and I’ve got a fresh start into the new year. First of all, thank you very much for having me with you. To you guys and also all the listeners, a happy new year as well.

James:

Thank you. So let’s start off with a quick introduction. If you don’t mind, can you let the listeners know who you are, what you do for Shopware, and please feel free to give a quick intro into what Shopware is and where you think the platform sits in the market.

Dominic:

All right. So we’re starting with me. I’m Dominic Klein, I’m working for Shopware in the technical specialists department, which is kind of a solution department. We are working together with customers and our partners. We’re integrators working on the one hand in pre-sales to help sell Shopware, and on the other hand to closely cooperate on existing projects and see how they’re going. And I’m helping our customers become successful in doing what they’re doing and making sure that they know how to use Shopware in a very good way. Shopware is a German ecommerce software company. We were founded in 2000 as an internet agency and since then have evolved into a software provider for ecommerce.

And yeah, in terms of market positioning, we see ourselves as a proven software provider. You can use our software to run your ecommerce shop and individualize it using plugins or custom extensions using the API, which I think we’re going to go further into afterwards. I used to be a developer at Shopware, so I have a tendency to get a bit more technical, so please let me know whether I’m going too deep in some places. But yeah, that’s where I come from.

James:

So that’s a really good intro. And don’t worry, getting too technical is actually what we want to do! We’ll do some high level stuff to help people who are more on the commercial side of the business to understand Shopware version 6. But for the more technical people in of our audience, getting under the hood of the API capabilities, that’s exactly what we want you to do. So don’t worry, you won’t be boring us. We love to get into the geeky levels of ecommerce. OK thanks the intro and for coming on the podcast. We appreciate that you taken the time so early in January.

As platform consultants, myself and Paul are always hugely excited when there’s a fundamental change to a key technology rather than just a major release or a minor feature release.

And from what we’ve learned in the conversations we’ve had through the end of 2019, the new version of Shopware is a complete architectural change, evolving into an API-first version. And that’s what we want to focus on today, to learn more about what drove this change and what it means to your clients and to other retailers who might be considering Shopware, as well as what’s coming next in the roadmap. Let’s start with the essentials and then we’ll get gradually into more geeky technical info. Are you ready for some questions Dominic?

Dominic:

Absolutely.

James:

Great, let’s get cracking. Let’s start with a nice simple one, which is “How is version 6 fundamentally different to version 5? And what drove that change? Why did Shopware decide to make this change?

Dominic:

Yes. You already mentioned that it’s been a fundamental architectural change compared to the previous version. Version 6 is actually the first rewrite of our software that we ever had. So up to version 5, it’s always been gradual improvements and reiterations of the same core of code, which evolved into the next versions. But Shopware 6 was the first one where we started with a blank sheet of paper. Shopware 5 had a rather monolithic structure where the different components were strongly coupled with each other, which often resulted in the system being difficult to extend in some places and we had to keep backwards compatibility that would ultimately break as in terms of innovation speed and adaptability.

So this is why we decided to rewrite from scratch where we focused on a modular design of the different components and also giving the ability to use the system via API. We focused on the ability of the ecommerce platform to integrate with other systems rather than being this self-contained software which, which is effectively what Shopware 5 was.

James:

So it sounds like there’s a mixture of your own internal technical capability, speed and efficiency within Shopware to accelerate the roadmap as well as the technical speed and agility of the client teams, which has driven the evolutions towards version 6 from5?

Dominic:

Absolutely. So when you look at it from the problem perspective or from the problem that we were trying to solve, it’s that businesses nowadays are not so much obsessed with the features that the modern ecommerce platform provides.

Instead they’re deploying different systems that are pretty good at doing a specific job and they want to somehow integrate those systems with one another. So we’re seeing more and more fragmentation of different software and solutions. And that’s a good thing because everyone’s really focusing on delivering the most value for their dedicated part, whether that’s email management, customer loyalty or another part of the overall ecommerce business. So we rethought our own position within that ecosystem or that whole constellation of systems and thought that it’s key to be able to integrate those systems really well with another and make that a smooth experience rather than having everything out of this single box.

Paul:

That makes sense. So I have a question. You talked a little bit about backwards compatibility. What’s the process for customers on the version 5 migrating to version 6? I know there are quite a few fundamental changes and you’ve got the change to the database structure. How does that migration process work? How long does it typically take?

Dominic:

That’s a question where many factors play into the answer. It starts with what size of business and what degree of individualization your store currently uses. We would be able to migrate a standard shop with maybe two or three plugins for payment and shipping integrations with a couple of clicks. But that, as you guys probably know better than I do, rarely the case. So we provide a tool that allows customers to migrate their data, which means customer data (customer passwords, orders, products, categories and all of that) from Shopware 5 into 6. The tool that provides the functionality also provides extension points so you can migrate your custom data fields from the old instance to the new instance as well.

But that being said, we have to really be clear about the fact that things like plugins or themes are not going to be compatible. So you will need replacements for a certain set of plugins. They already are some replacements in version 6, especially for the most used like payment providers. Store locators are very, very popular plugins amongst our customers and those can be used in Shopware 6 as well. When it comes to themes and things you have individualized in your shop or integrations with other systems, those have to be taken to the new system as well and this typically adds complexity and time.

James:

The other day I was looking at some of the plugins on your online marketplace. Looking at compatibility with versions, how do you plan to kind of get more of those plugins working with version 6 and also with the ones that were previously maintained by Shopware but aren’t in the new platform version? Is it within your roadmap to get those into version 6 natively, or to encourage more extensions in the marketplace?

Dominic:

Yeah, you’re actually mentioning a very important thing here. We provide plugins that are officially maintained by Shopware and there are also marketplace extensions, which we call plugin manufacturers. So in order to make sure that these plugins are maintained in version 6 as well, it is kind of a push and a pull, right. We are creating a new product and in the beginning people hesitate to use this product. We have to create a push in some way and realised all of the plugin manufacturers needed to get ahead and get familiar with the new system. We informed them what the changes were and why we did it. The plugin manufacturers were able to define a roadmap for their plugins for the new platform version.

Our partners and customers have transparency about when they can expect a certain plugin or a given function to be available in Shopware 6. We have taken different strategies depending on the capability. We decided to pull some of the plugins that were provided in Shopware 5 in the core functionality and let customers use specialist third parties because they are better at solving certain problems. We try to focus on the problems that we want to solve for customers.

Paul:

That makes sense. Do you have any live sites on version 6 at the moment?

Dominic:

We do have a couple of life sides right now. I haven’t prepared a list of them right now. If anyone would like more info, then please reach out via Twitter: https://twitter.com/elkmod.  So I’ve got a little gift for anyone who can guess why that is my Twitter handle. On my Twitter stream you’ll find examples of projects. There are some bigger projects that are currently happening in the background but I’m afraid I’m not allowed to talk about them publicly yet.

James:

Fair enough, we won’t push you! Something I’d like to get into a bit more detail with please Dominic is what API-first means to Shopware. I think people hear things like API, API-first, headless and it can mean subtly different things depending on who’s saying it. Let’s split the question into two parts:

1. What does API first mean to Shopware?
2. Which parts of the platform are opened up and exposed to the API currently?

Dominic:

I’d like to explain the meaning of API-first by first defining what headless means to us, and how that leads into API-first. So ‘headless architecture’ is a term which is more commonly agreed on. So that means decoupling your application front-end from your application back-end. So where all the logic is happening, you want to have that decoupled from the presentation layer. This sort of decoupling enables the headless architecture of our system. API-first on the other hand is an approach to how you design the system.

A traditional approach would be to build the interface of the system and then make sure that every piece of the interface can be delivered by an API or the corresponding data can be delivered by API. Instead, we first defined that set of functionalities that we need then built the corresponding APIs. And then using those APIs or API endpoints, we built the interface. And this way we make sure that every piece of functionality that the shop provides, and that kind of answers your second question, is provided by a corresponding API endpoint and also gives us the ability to switch the different interfaces, the different front-ends of the shop. And that really shines when you look at some examples like the collaboration with Vue Storefront to provide a native PWA solution for Shopware 6, which is entirely relying on the core API.

There are also some other examples of the benefit of being API-first, for example extracting the checkout from Shopware. You could be running a WordPress site, so you’re very content driven but at some place you need to have an ecommerce checkout. You can use our sales channel API. You can add different products into your shopping cart and then use the Shopware checkout in a headless mode, which means that essentially you’re just pushing data between this API channel and the end customer always stays within your WordPress site.

Paul:

You mentioned Vue Storefront and I’ve seen Shopware talk quite a lot about the integration. Are you planning on building integrations with different frameworks or headless CMS solutions?

Dominic:

PWA is obviously something that is very demanded on the market. So many of our customers are very interested in this topic. We think we’ve found a very good partner in Vue Storefront with a lot of experience of actually delivering PWA solutions and we’re very happy about being able to build a dedicated tool together with them when it comes to integrations with other systems. There was nothing that we’re currently planning to do out of the box in terms of integrating with other CMS systems or other front-end solutions.

However, our current architecture is fully based on Symfony. It allows for lots of other tools to be integrated, such as other headless software tools like Drupal CMS for example. They offer SDKs that let you integrate Shopware pretty easily. Using those core libraries you can individualize your integration with that system. And that’s also something that we see as a pretty good selling point of Shopware. Symfony is really nice for developers because we are using the standards that Symfony offers. You can use tools which are already there and then just put them in the right place more or less. So the developing experience is a very nice one. And that is one of the things that we tried to focus on instead of delivering everything out of the box.

James:

It sounds like a sensible approach and I know a few agencies whose development teams have said Shopware 6 is really nice to develop on. I want to just pull it back to the API thing to clarify for our listeners. When people sometimes look at platforms with API capabilities, it can be a bit misleading about what you can actually expose via API. How much is accessible? How extensive is the API across all of the capabilities? For example, is the checkout completely opened up by API? Could you create custom checkout flows? Is there a or is there anything locked down where actually the merchant can’t access a data end point via the API?

Dominic:

The checkout is the standard checkout that Shopware provides and it’s currently fully API supported. We’ve got a growing ecosystem of integrations and extensions for Shopware 6. We currently haven’t found a way to ensure that each of these integrations is also the part of API endpoints that Shopware provides. Within our own domain of the functionalities that we provide, we maintain API coverage but when it comes to third party extensions. it is up to them to align

James:

I think that’s a really important distinction, understanding that your platform, the core application, is API enabled. However, a third party tool that somebody might be using in conjunction with Shopware might not have a robust API. Therefore that needs to be considered in terms of how it could bets integrate with Shopware from an ecommerce point of view. Thank you for clarifying that. In terms of the API, can a merchant using Shopware 6 extend the API or is it locked down, as in you can’t do any customisation?

Dominic:

Yeah. You obviously are not supposed to change any parts of the core API, right? We have documentation which dictates how the API behaves. But you’re absolutely able to add custom end points to the API. So that is pretty close to the Symfony standard actually. It’s more or less just adding another controller heading, adding custom routes and then authentication of the API. Your extended or your new endpoints will be under the same routes as the core Shopware API. You can prefix it, you can utilize versioning of the API. So we enable all that. But we are not quite at the point, as I said before, where we can really force everyone to be doing that. We are strongly encouraging plugin manufacturers where it actually makes sense to have a robust API coverage to, to do so.

James:

Thanks for clarifying that as well. If a merchant takes your core API, they then extend it because they want a custom end point, Is there ever any risk of when you then release updates to version 6, like minor releases, would it ever cause any compatibility issues with extended endpoints?

Dominic:

We will support every old version of the API when you step back one minor version. Let’s get a bit more and more concrete with an example. So there is Shopware version 6.0 and we then introduce a certain API end point. Then there will be Shopware 6.1, where we deprecate maybe a certain field of this API end point that will mean that in 6.2, this field would be removed. However you would still be able to, to read and write that field. But that would be a conversion in the background that will make sure that this field gets written and changes that have been made in prior versions are converted to the new structure. By gradually deprecating a certain field, we make sure to maintain at least predictable comparability of certain end points or certain fields within those end points. And we’ve defined a standard on how to actually do those transitions. We can only encourage extension manufacturers to do so in order to provide the same benefits for their plugins.

Paul:

I have another question. With Shopware 5, when you first moved into the UK, one of the big selling points of the platform was the page builder and content management capabilities from an API perspective. How much of this is available and how would this work when you’re using a separate front end framework or CMS?

Dominic:

Ah, that’s a very interesting question because when it comes to CMS what you often have in mind is that visual editor, right? Which lets you build your pages and pull them together and what you’re seeing inside your preview is what you’re getting in the end. They are actually many tools which do this in a very good way. But then it comes to Shopware being headless having this way of thinking about different sales channels, which inherently mean that there’s going to be a different way of displaying the content. So content in Shopware is maintained in a structural way. We store the structure of the content. For example a component has a heading, a paragraph and an image followed by a list of products, but we don’t store any channel specific layout information with it.

So it’s not being stored as HTML for example. We actually let the front end interpret this data structure and render it in the corresponding way. For example, we’ve done exactly that in the PWA integration. So it uses the sales channel API, the API delivers the content in a structural way. It’s a Json object and then this Json object is interpreted in the Vue Storefront CMS package and rendered as HTML to the user.

James:

That makes sense. The individual elements being requested. So some really useful insights and especially some technical clarification on the API. So thanks for that Dominic. What we’d like to do now is talk a bit more about the product roadmap for the version 6 platform. Let’s talk a bit more about that now.

Again, let’s start with a nice simple question and then we’ll get into a bit more detail. So what would be really interesting for listeners is to understand, is that there’s a slight change in terms of overall functional capability where some features have been removed from the platform, such as Wishlist, and a lot more has been baked into the core platform, such as an advanced rule builder. What I’d like to understand is how does the Shopware team prioritize the roadmap and decide what had to go in for launch versus what might come later. Y

Dominic:

We try to focus on which features deliver most value, the features that merchants actually need to run their online shop. And which features might be convenient, nice to have but merchants aren’t asking for it straight away.

That’s obviously a very general way of going about it. So we looked at our customers and saw, okay, what are the requirements of customers using Shopware 5 and thinking about transitioning to 6, and what are the requirements of customers who are thinking about replatforming. So that’s what drove the prioritization for us. We’ve got a detailed roadmap on our website, which you can actually look into and being open about it is one of our core goals because version 6 is a new product and somehow you have to gain trust of the community. If you don’t, if you’re not transparent about what your plans are, what your roadmap is and try to sell something which is not really there, you’ll erode that trust. So that’s what we absolutely don’t want to do.

Paul:

So what isn’t available yet in version 6? Are there some things that you’re planning on removing completely and what’s the intended time frame for this?

Dominic:

So there are some features that we are currently working on. Those are some things like product bundle, product comparisons and product personalisation, which we’re currently scheduling for mid 2020. So say you want to have a tee shirt and customize via printed text or you want to have it fabricated in different ways, that’s in the pipeline. We’re currently working on some extended CMS features. We want to provide an editorial system where you have content staging as well, where you can have confirmations by different employees, by different users in the administration. Those kinds of features which we’re targeting for the end of 2020.

Paul:

And I read somewhere that you’ve improved the international offering of the platform and you’ve added some new features here. What do these look like?

Dominic:

There’s actually a shift in approach, as part of the platform rewrite. Shopware 5 was an inherently German product, which resulted in default values in a database being a German string like “nicht verfügbar”, which means “not available”. It would be when a product is out of stock. Those things kind of grew organically into this software and that was why the Shopware 5 release struggled in some places to be fully international, as the admin tools weren’t easily comprehensible. For Shopware 6, making the software accessible to an international audience was one of the main focus points. So there was no default language, for example; you can initialize Shopware 6 when you install it and then you can set your preferred system language.

For international ecommerce, you can define rules for shipping, pricing and payment providers when they are available at country level. Shopware 6 offers a Rule Builder, which lets you assemble rules using multiple conditions and those conditions can have something to do with the context. Like what’s the amount of items in the cart when was the user registered, which kind of categories have they bought in before. And using those rules you can define product availability and pricing, as well as custom rates for shipping based on destination.

Besides the content being fully translatable, which is what merchants now expect, we aere also working on having individualized content based on those rules. So let’s say in a certain country you want content would be richer in pictures and other countries you want to have more text or something like this. Internationalization is inherently done in all modules or components of the software.

Paul:

Getting back to the roadmap, what incremental functionality is coming in 2020?

Dominic:

So what we want to extend is the CMS and the editorial features. Something else that we want to have is a data set manager, which is really just the generalization of the CMS. So instead of maintaining content as in pages, we want to enable maintaining different types of content. Similar to how some content management systems actually do it right now. So you can define data types, let’s say recipes or local stores or something. And then those types can have different fields. And then you can use those types to produce listing pages to produce detailed pages and then use them of course over the API as well, but then present them to your customers data model within whatever CMS they are using, for example Contentful.

Paul:

One last question. A couple of years ago I went to the Shopware Community day and I remember you talking quite a lot about AI (artificial intelligence) and how you plan to use AI within the platform. Could you just talk a little bit about that and what the plan is?

Dominic:

What that will look like? Yeah. so in general it will involve a lot of research in different topics. I have to admit that AI is a topic that has grown to quite a hype in the past couple of years. And the interpretation of what AI means for different applications has been very broad as well. So sometimes AI, for example, means that you have rules and based on these rules, the system behaves differently, like a kind of a decision tree.

So that’s what Shopware already does. We’re providing these rules and based on those rules we can have individualized behaviour of the shop but that’s not what I really consider AI. AI in terms of consuming massive amounts of data and based on those data generate predictive models that is something that is a more inherent to things like CRO (conversion rate optimization), AB testing. There are specialist tools that we’d rather link to than try and provide ourselves because that isn’t our core expertise. We focus on providing the data that is required for other solutions and the corresponding algorithms.

James:

So effectively you’re looking to work more with third parties rather than bake AI into the platform. I guess a nice way to summarize, is that essentially you develop the new platform version to be as open as possible from a data and API point of view so that people can create a best in class infrastructure using specialist tools for certain areas where it doesn’t make sense to bake into an ecommerce platform because there’s already market leading tools out there.

Dominic:

Absolutely. That sums it up pretty well. We are now in the age of platforms. It’s not really up to one tool to incorporate everything because there are so many.  We’ve evolved and there are mature solutions out there which you can use. Of course, you’ll have the effort of integrating them but that’s exactly the point that we want to want address with the API-first version. Instead of baking everything into one application, which is in the end harder to manage and extend. That’s, that’s our ultimate goal.

James:

It’s where some other platforms have tried to try to evolve as well, as it’s this whole point of wanting an ecommerce platform to do what ecommerce is good at, which is to help you to sell across all the channels. If you need to use a specialist tool for something else, whether it’s a CMS or CRM, then the ecommerce platform has got to be flexible enough to plug and play with various tools and not make it, as you alluded to earlier, a monolith that is massively slow and costly to make any changes to .

Wow, the time is flying. I’ve just realized Dominic that we’re already about 40 minutes in, which is amazing. It’s always good fun talking about these things and you’ve answered all of the key questions. The last thing to ask you, is there anything else you’d like to add in terms of how you want to position the new platform version to our listeners?

Dominic:

I’ll just sum up what I’ve said so far. I suppose some or most of your listeners haven’t really got their hands on Shopware either. I invite you to visit our website and inform yourself about what we can do. If you want to have a general overview of the key features and what our software can do, from a developers perspective you can have your own instance. Let me know and I can help you get started. Feel free to reach out to me either using LinkedIn or Twitter: https://twitter.com/elkmod

James:

Thank you Dominic for taking time to join us and share your insights and knowledge with myself and Paul. If anyone listening would like to learn more about Shopware 6, do let Dominic know – the post on our website will have relevant links and contact details.

So that’s the end of episode nine of the Re:platform podcast. Thank you everyone for listening. The podcast is available in RSS if you want to get a subscription. It’s also on the popular podcast channels like Spotify, Google and Apple if you prefer to listen there.

If you’d like alerts for our latest podcasts, please sign up to our newsletter via the website. As soon as the new episode is available we’ll let you know. Any questions about today’s episode? Get in touch with myself or Paul.

Thanks very much for listening. Take care and have a lovely day.