Headless B2B marketplace?

The eCommerce world is undergoing a major new evolution step, moving away from tightly coupled monoliths towards modular monoliths. I know the word monolith has a lot of bad connotations in the IT world but I think this image is a bit of a knee jerk reaction. In most cases a monoliths is the right starting point for a project. The key thing is choosing a monolith that allows for evolution as the project scope or needs expand or change. This is something that eCommerce solutions of the past tended to fail at, hence the bad image for monoliths. Magento v1 is an awesome eCommerce platform as long as the needs for customization fit within the bounds hardcoded into the code base. However simply replacing Magento v1 by a micro service architecture would maybe prevent any hardcoded walls but would bring productivity to a halt. Martin Fowler states “don’t even consider microservices unless you have a system that’s too complex to manage as a monolith”. Or the corollary to this: Microservices must help to simply your system.

With this precursor out of the way, lets look at some of the emerging players in the eCommerce space and since I am currently evaluating options for a concrete project lets look at them with the requirement working as a headless B2B marketplace. But let me briefly explain those requirements

Headless

The customer is aiming to provide multiple touch points. As such there will be a web interface for desktop class monitors which will get the initial focus. But there will be potentially additional desktop optimized UIs but more importantly various mobile apps (maybe one focusing on purchasing, another focused on logistics etc) down the line. As such the eCommerce platform needs to make it possible to easily get to the data and business logic via some sort of API.

B2B

Business to business generally changes requirements quite a bit from changing the focus from presentation to efficiency. On a B2B website keyboard short cuts will have higher relevance than on a B2C site for example. Searching by SKUs or ability to scan barcodes are also more relevant. So are topics like permissions management to define who can fill shopping carts and who can complete purchases. Multiple shopping carts, shopping lists, repeat orders etc are also classic B2B requirements. Topic like up-selling are also relevant but might need a different spin due to the separation of people choosing products and people completing purchases. Also pricing is very different from B2C. Starting from using non VAT prices to customer and quantity specific rules.

Marketplace

On a marketplace there are more than one merchant selling products. Usually any product can be sold by multiple merchants each with their own price and stock. Meta data however tends to be normalized across all merchants creating additional challenges in how to import that data and ensuring high consistent quality. Shipping costs and even more importantly handling of returns also become considerably more complex.

So lets look at some of the contenders ..

Magento v2

I should rather say v2.2, since previous versions were plagued by bugs and releases contained a lot of backward compatibility issues. The new release promises to finally stabilize the APIs and a good sign here is that finally Magento is more actively integrating the feedback of the community into the release and development process. My fellow Liiper Maxim is quite happy with how things are going there. I am not entirely sure why they build so much infrastructure code rather than just using ZF2+ or Symfony but over all they implemented similar patterns which enable easier refactoring and extensibility. Magento is also taking B2B more and more seriously but out of the box the feature set still needs a bit work. Overall Magento v2 is a big step forward from v1 however its also clear that the code was refactored not entirely reinvented. The big advantage of Magento is of course still its huge community. While the code is open source, for bigger projects we would recommend using their Enterprise offering. Unfortunately they do not seem to provide a good overview of the differences.

Spryker

Spryker is kind of a hype at the moment. I say hype not in the negative sense here, they simply managed to get a lot of attention very quickly. Quite impressive! One of the things that makes Spryker unique is that they denormalize relational data into Redis, which enables high performance without a reverse proxy. That being said, reverse proxies and invalidation are challenges but they are well understood. Also when working with international customers, a reverse proxy in different regions around the world might be necessary anyway. Keeping the data in Redis sufficiently in sync provides a challenge that is unique to Spryker. On the siroop.ch project, who are using an older version of Spryker, I saw this was a constant source for issues. They are rewriting this part right now so hopefully this will be less painful in the future. They also told me that they will improve the management of the data contract between the system writing to Redis (Zed) and reading from Redis (Yves) more explict. Another aspect which sets Spryker apart is that their backend is designed to enable separating f.e. user management and ordered management onto different servers if necessary. This architecture could lend itself to flowing more naturally into a micro service architecture. They are planning to add B2B features and even marketplace functionality to the core, but these features will only start appearing in the coming months. In the same way while Zed and Yves talk via HTTP, Yves itself isn’t made for headless setups out of the box. Here again they are planning to soon over a solution. They are hopeful that the first such features will start landing this year already. Their licensing is a bit unique in that one pays for developer seats.

My main criticism of Spryker is that due to being based on Silex, rather than on Symfony full stack, they are lacking a lot of developer productivity tools. For example to solve performance issues, they have multiple independent Pimple, ie. DI containers, for each module. This in turn means its impossible to get a global overview of available services. For the routing they could in theory provide something like this fairly easily but have not emphasized this.

Sylius

I followed this project from its very beginning when Pawel started appearing on the #symfony IRC channel. His attention to quality impressed me right away and really shows in Sylius starting with the use of BDD which is also a great way to document behavior via test code. While initially this perfectionism prevented him building a community, the project has long overcome this and is now quite an active community. On top of this there is now a company dedicated to Sylius support and training. The code is entirely open source, no enterprise versions or other licensing fees. They are now very close to that very first 1.0 release. However releases for a while have come with quite detailed upgrade instructions whenever backwards compatibility breaks had to be done. In terms of modularity I think they are on par with Spryker. Given that they are build on Symfony fullstack framework, its also easy to leverage and integrate with the countless Bundles out there. Their large set of re-useable components are also ready to be used even outside of Sylius itself. I am also quite excited about their attention to single page apps (SPA).

OroCommerce

The Oro team, given that they are essentially a lof of ex-Magento core developers, is certainly quite experienced in eCommerce. Their first product was OroPlatform and OroCRM, which are both interested topics for customers that want to highly customize their CRM or that simply want to build desktop-style custom applications. OroCommerce is a bit younger but they emphasized B2B very early on. I suspect because they sensed that Magento v2 didn’t initially put much of a focus on B2B. Similar to Sylius they are based on Symfony fullstack. In terms of licensing they offer a free open source basic version but the Enterprise version seems necessary for larger projects. I feel like they have not yet really managed to build a large community.

DrupalCommerce v2

While Drupal 8 certainly improved its core towards easier and cleaner extensibility by adopting interfaces, I would still argue that form the lists in this post, its still the one that is most like the monoliths of the old days. However DrupalCommerce still manages to be remarkably extensible. We build Freitag.ch on Drupal 7 and Commerce v1 which is very unique in that most products on the store are unique. Their next version, which builds on Drupal 8, looks to further improve here. They basically started by first building re-useable components which they then integrated into Drupal to build version 2 which just reached RC1 status. Where DrupalCommerce has always shined, which is the reason why we picked it for Freitag.ch, was the fact that that through Drupal it provides a full featured CMS where the commerce parts are first class citizens. This means that advanced story telling is possible, entirely driven by content authors, rather than requiring a development sprint for each bigger change. As such, story telling does not tend to be a key requirement for B2B for now but I think it will become more relevant. Those companies that have been holding out with adoption digital B2B mostly did so exactly because they felt that with the approach most companies are taking, the inspiration part of the commerce experience was lacking. The code is fully open source and consulting offerings are available

What it all means ..?

Quite honestly I am very impressed with this new generation of eCommerce solutions. All of them have different strengths and weaknesses.

Spryker has a unique architecture that sets it apart from the rest, which however also means in terms of minimal setup it has the most moving parts. Sylius, OroCommerce and DrupalCommerce all are based on a larger ecosystem which will allow integration of other features and even applications quite seamlessly.

Sylius and DrupalCommerce are fully open source, while Magento and OroCommerce provide Enterprise offerings which are really sort of required for serious work. Spryker again goes a different direction by requiring developer licenses. They all have companies behind them that offer commercial support when needed. In terms of community Magento seems to have the lead and OroCommerce seems to be struggling here a bit.

Sylius is the only option that from what I am aware have stated to have headless/SPA as a focus. All of them currently provide the key APIs necessary with Spryker lagging behind a bit since Yves out of the box does not provide any API yet.

What all of the projects on this list have in common: They are still in a fairly young state of development either only gone stable in the past year or two .. or even just approaching the first stable release. The good news is of course this means that there will still many years of support for those versions and the ecosystems will continue to grow. However in terms of getting things done quickly for more standard eCommerce requirements, Magento v1 probably still beats them all.

Hi Lukas,

Thanks for your post.

I read it with great interest as I’m watching this space pretty closely and found that the open-source space for B2B shops, let alone marketplaces is very thin.

After reading through your post, I found the title a little misleading, not to say click-baity 😉 Let me explain.

Basically, you approach the topic from an architectural standpoint. The question you asked seems more like: what are “potential ecommerce solutions that provide a good foundation/framework for (substantial) custom development to create a B2B and/or a marketplace solution – and provide a clean API to build your own UI on top”.

If you would be very strict in terms of B2B and marketplace requirements, probably all of your discussed solutions don’t match the criteria. Some have B2B features but none has marketplace features…

One very strong contender that does all you are asking for out-of-the-box is Oscar Commerce [1] which is build on top of Django. So, it’s not PHP and probably you should state it explicitly that PHP is a requirement.

Knowing your and Liip’s background it’s probably not a practicable option to use Oscar/Django/Python. However, I can warmly recommend the very good documentation [2] which explains the design concepts of a multi-merchant ecommerce platform. There is also a sandbox [3] to play a round, but it’s very simple to install and run a sandbox locally.

[1] http://oscarcommerce.com/ – Oscar
[2] http://docs.oscarcommerce.com/ – Documentation
[3] http://latest.oscarcommerce.com/ – Sandbox

Hi Tim :)

From my understanding Oscar is multi tenant capable out of the box but not necessarily a marketplace in the sense that multiple vendors can sell the same products at different prices with different stock.

Both Sylius and Spryker I know are looking into the marketplace topic but indeed they do not have any solutions to offer there either.

All of the items on the list can provide multiple shops and to varying degree also du multi tenant, which again isn’t the same as a marketplace (at least in the definition I am using).

Another dimension is that Python is still a niche world. Oscar has been around for years with multiple stable releases since 2014. Yet the core repository still has less than 200 contributors (https://github.com/django-oscar/django-oscar/graphs/contributors). This of course is a sizable amount, but Sylius, that is yet to even have a stable release already has over 400 contributors (https://github.com/Sylius/Sylius). What I mean to say is that yes, I focused on PHP solutions (partly due to my background, partly due to the customers background). But this “bias” is rooted in simply PHP having a much better track record in eCommerce, leading to a bigger community to help drive things forward or simply in ability to hire developers when needed. But of course depending on the team of developers available and strategy, Python and the many very high quality libraries and applications within that ecosystem make fine options.

Leave a Reply