Shopware 6 is by far one of the most extensible and full-fledged PHP eCommerce platforms available on the market. It can be customized by non-technical users and developers alike. The three underlying principles that drive its flexibility are:
- Strongly event-driven approach,
- Built with cloud-based solutions in mind,
- API-first architecture from the bottom up.
This article discusses all of these traits in the context of apps and plugins for e-commerce industry and at the same time compares their strengths and weaknesses. Apps and plugins are collectively known as extensions in the Shopware ecosystem.
Plugins
Overview
Plugins are extensions that are hosted directly on a running Shopware instance. Users can deploy them in a variety of ways listed below. They’re used to customize the user experience, shipping & payment methods, themes and much more.
Plugin management
Plugin manager
The built-in plugin manager enables a non-technical user to easily install new plugins by uploading ZIP archives. A plugin that gets installed this way is instantaneously available as soon as it’s activated.
Advantages
Ease of installation may sound inviting for those who want to use a particular plugin without the hassle of tinkering with the server-side part. An intuitive graphical interface guides the user through the installation process. Plus there’s no coding involved.
Disadvantages
While attaining the desired outcome in just a few steps is tempting, you should be aware of a couple of things. First, uploading ZIP archives can be potentially risky to the system. After all, you can’t really inspect code quality and how it affects your shop.
Secondly, it can be problematic with regard to updates. Oftentimes, it means re-uploading the plugin numerous times. Definitely, it’s not for the faint-hearted.
Manual installation
If you’re a technical person yourself or your company business gets help from developers and lastly – if you’re a developer yourself – installing new plugins from source code can be a viable option.
Advantages
First and foremost, the programmer can read the plugin’s code and decide whether it poses any threat to the stability of your shop. Let’s say you offer an eCommerce platform as a part of a bigger SaaS that’s the central point of your business. If your helpdesk processes a lot of client requests to add new plugins, your developers can establish a streamlined process of verifying plugin compatibility with your company’s best practices.
Disadvantages
If you’re dealing with third-party code, sometimes it’s hard to resist the temptation of modifying it. This can lead to serious maintenance problems when a new version of the plugin is available. Coping with source code conflicts is daunting. Generally, it’s considered a bad practice.
Shopware store
Last but not least, the most obvious way of getting new plugins up and running is by installing them using the Shopware web store. It’s by far the most reliable way of customizing your shop if you’re not a tech-savvy user.
Advantages
Plugins acquired in the Shopware store offer rock-solid and battle-tested solutions, be it basic shipping or payment integrations or more involved specialty services like PIMs.
Disadvantages
It can come at a literal price. This is especially important to consider when you first start out with your business. How much you can invest in your shop is crucial. Additionally, plugins have two billing models:
- Pay once and use forever,
- Subscriptions.
Both forms of billing do mean that you’ll probably get new updates as soon as they’re released. But mind that it might take some time for the updates to roll out.
Shopware – All-In-One eCommerce Platform That Meets The Highest Requirements
Plugin development
There are times when simply customizing your shop with extensions you can find online does not suffice. But this doesn’t mean that the process of creating new plugins needs to be tedious. Quite the contrary – Shopware offers a unified way of developing solutions that are tailored to your needs.
Advantages
Using Shopware codebase to the fullest
Having a skilled PHP developer with knowledge of modern Symfony and basics of e-commerce know-how is just about enough for them to learn how to build state-of-the-art plugins. Although extensive, Shopware’s APIs and documentation are there to help.
Ease of maintenance
When one decides to develop custom plugins for an e-commerce website, there’s no need to depend on third-party vendors to update them when bugs pop up and impede the overall experience of your customers in one way or another. Also, in-house plugins’ code can be hosted in your private repositories. What that means is you don’t have to worry about the plugin crashing one day and then having to wait several weeks for the third-party developer to fix it.
Complex frontend management made easy
Building custom themes, and complex user interfaces in the admin panel and the storefront is right at the developer’s fingertips. Shopware offers a library of components that are re-usable across the whole admin panel. They simplify day-to-day programming tasks so there is no bloated boilerplate code involved in setting up the plugin.
Disadvantages
Monolithic approach
Shopware plugins are tightly coupled to the Shopware system as a whole. Even if a current major version guarantees that the framework won’t change its workings now, it does not necessarily mean it will never change. When developing a custom solution, being mindful of breaking changes and adjusting the codebase is of utmost importance, provided you want to stay up-to-day with new Shopware releases.
This might sound a bit like an aggressive oversimplification and a trivial cliche but software does change over time.
Shopware 6 app development
Overview
According to Shopware documentation on apps, they’re a less intrusive pattern introduced to develop solutions in the cloud. They offer pretty much the same functionalities and customization methods as plugins, including theming, shipping, product management and payments. As such, they’re comparable in terms of what they can do.
Installation methods
Shopware apps can be installed using the same channels as plugins. The main difference though is – apps do not contain any code by themselves when installed in your shop. Instead, what you get is a simple markup manifest file. This file describes various events that a remote app can respond to and decide what to do when:
- The app is installed, activated, inactivated, uninstalled,
- Entities in the database change (product is modified, an item is added to cart),
- Payment and shipping states are updated,
- Authorized users perform administrative tasks in the back office panel,
and much more.
From the point of view of a Shopware instance, the manifest file is self-contained and does not need any further configuration.
The caveat is that extensions, including apps, can get a bit pricy depending on your and your customers’ needs.
App core principles
Event-driven approach
This is a very popular and well-established model of separating concerns during development. In a nutshell, it’s about reacting to predefined conditions (events). Events drive the system, hence the name.
A good example is a newsletter app. You can listen to business events happening in your web store and send emails to your customers in a flash. Emails could of course be queued and dispatched whenever you see fit.
Another example is a plugin for generating shipping labels. Once an order has been placed, your app can send a request to an external API to get a label. The obvious advantage here is that the labels would be available on-demand and could be stored in a remote filesystem. That way, your Shopware instance doesn’t have to store label files in the media directory.
Cloud-based deployment
One of the most prominent features that set apart apps from plugins is the deployment model. The concept of apps was specifically invented with cloud architecture in mind. From a DevOps perspective, this means a lot. They’re easily containerized and orchestrated with tools like Kubernetes (means of achieving self-managing and self-healing units with all of their dependencies contained within a single package).
API-first architecture
There have been a lot of changes in the PHP world over the past few years regarding how web apps are structured. The „classical” way is when the server generates HTML web pages that are being output to the browser, based on the end user’s input. The Shopware app system takes a drastically different approach.
Instead, upon request Shopware prepares a JSON response (think of it as a data description format). This is a characteristic that’s pervasive throughout the platform:
- The admin panel is developed this way in its entirety,
- Storefronts like Shopware PWA use it to create unified interfaces that are suited for browsers and mobile devices alike, ensuring a better user experience.
But most importantly, from the point of view of this article – this mechanism is also used in Shopware apps. Shopware provides a facility called webhooks. When an event happens that your app decided to react to, Shopware sends a notification to the web server where the app is hosted. Then your app handles such notifications and decides what to do with them. It can process the data, store it, or even ask Shopware to send some additional information. The API is unified and versioned so the developer can expect that it won’t change as long as they use a specific version.
Shopware Plugin and App Development & Customization
Upsides
Development in any programming language
An astute, technically inclined reader might have guessed by now that since apps only communicate with Shopware via an API they can be developed in any programming language capable of the secure client-server communication. Of course, if you already use PHP it’s a great language for creating complex apps suited to your needs.
Separate deployment
Apps do not depend on a particular Shopware instance. They’re completely separated from what happens on the server where a Shopware instance is running. This has interesting consequences, for example:
- They can be fixed and updated independently from the shop,
- They can serve multiple instances at the same time.
Embedding custom interfaces
At first glance, it might not be obvious but apps can add custom interface elements. This is made possible by two basic ingredients:
- App manifest – this file, which is described above, allows the programmer to embed a configuration interface for the app. Additionally, the app can create „action buttons” and assign them custom hooks that the app will react to.
- iframes – apps can embed fully customizable iframes. The app’s backend is responsible for generating the interface while the app’s frontend renders the iframe that can be shown virtually anywhere in the admin panel.
Downsides
As with plugins, there is no such thing as an ultimately winning choice. There are tradeoffs that need to be considered. It all boils down to what you need and the means of achieving the desired effect that you can employ.
Resources
Shopware apps need to be hosted externally. If you use a third-party service like Mailchimp, you don’t have to worry about resources at all. But if you develop apps in order to decouple the different components of your shop you need to be aware that apps take up resources. Typical scenarios include:
- Data caching – you don’t want to send requests too often. But when you cache data (store it temporarily) it’s advisory to make sure you have enough space to do so.
- Persistence – if you aggregate and process data coming from Shopware, you need to persist them in the database. Excessive or outdated information that may accumulate can become a bottleneck over time.
- Multiple requests – if there’s a lot of activity happening in your shop there can be a lot of notifications to process. Depending on your server setup, handling them immediately as they come can be overkill. A good practice is to queue the notifications and process them later on if they don’t need to be dealt with synchronously.
Security concerns
When you develop apps for your shop or your clients, it’s your responsibility to take care of all security measures that must be taken in order to offer a reliable and safe service. The communication between your app and Shopware needs to be secured via encryption and your database server must be protected from the outside world.
Of course, there are tools to overcome security shortcomings if need be and this doesn’t mean that apps are inherently unsafe because of this.
Service uptime
Last but not least – the uptime of your apps needs to be monitored. With plugins, it’s easier to discern if and when they fail since your shop might become unresponsive when a critical situation arises. This, in fact, is a serious downside of plugins though – since apps are decoupled from the rest of the system it’s much easier to deal with broken apps that can be serviced separately. However, it’s another thing that you shouldn’t be worried about if you use third-party apps. They usually operate on a large scale and thus guarantee high uptime rates.
Final thoughts
If after reading this article you get the feeling that it’s not conclusive – that’s absolutely right. Neither solution is better. The choice between apps and plugins is best summarized with two words – „it depends”. Both business and development-wise there are things that might prove more effective in the long run. One ought to plan out what’s best and pursue it. Not at all costs though, it’s perfectly fine to change your mind in the process if things go sideways. If you feel we can help you, do not hesitate to contact us.