Magento as a black box – the use of ecommerce microservices – part 1

 If you have ever flown in an aeroplane, you should know the idea of a black box – a small element of the plane that records everything that is happening during the flight, so in a worst-case scenario, we can recreate the last few seconds of the flight.   

But there is another definition of a black box in IT that can be presented as a complex system or device whose internal workings are hidden or not readily understood. It is this and the related matter of building microservices for ecommerce that we will be addressing in this two-part article.  

Ecommerce microservices in a black box concept  

In this concept – a black box is a magical box that does its things, but no one knows how. If we could transplant this idea into ecommerce, this would be easily represented as SaaS – software as a service, where the user (owner of the business) does not know how the service mentioned above works. It works great for such platforms and is heavily represented on the scene. Some well-known names are BigCommerce, commerce tools, Wix, Shopify.    

But the first question that arises is: where is the business logic stored if not in the platform?   

This is where the idea shines. At the base, this black box creation has all the basic functionalities of the ecommerce platform, such as products, categories, customers, carts, checkout, payments, delivery and so on. Those basics can then easily be used to create more complex constructions not on the service itself, but just alongside, as microservices for ecommerce. So, for instance, if you need to calculate a new special price based on some rule, we shouldn’t do this in an ecommerce platform, but we should instead build a dedicated tool just for that, connect with API and store the price in a field that was already predefined.    

Such a microservice architecture allows us to deploy changes for different services more quickly and more frequently. Additionally, looking at it also from the developer perspective, we can use different languages and tools to create such microservices, thus making such work more pleasant for the team.  

But can Magento – a platform dedicated to customisation – be such a black box, and is it actually a good idea?   

The answer is yes, but…   

API first   

Magento has particularly good API coverage – while using the API (REST/GraphQL), you can do everything there is to do, not only from the customer front but also from the clients’ backend. Whether it’s order handling or stock management, uploading products or catalogue configuration – we can do this using API-connected microservices for ecommerce.  

Cost of Magento customisation   

Magento is known for many things, but its customisation properties are one of the best in the market. Do you need some specific functionalities? If it is not already built-in, then there is a high chance that it can be bought. But what if there is nothing off the shelf? Of course, you can get developers and pay them to create some logic and custom code, but you will quickly understand that it is not cheap.    

Magento developers are expensive, and considering that it is not corporate-level software, it can turn out to be a bit too expensive for most mid-size clients.    

Now, here’s where the marvellous concept of microservices for ecommerce comes in. Thanks to this concept, you are not restricted by technology and niche markets (it is not niche per se, but it is a bit closed), and you can more easily find a team that maybe won’t even break your budget.    

Business logic separation   

Once you start treating Magento as a black box, you will move all your business logic to your own curated services, and you won’t be restricted by things Adobe decided to do. However, there is another side to this too. For example, once your logic of special price calculation is decided, it can be something completely different than the calculation of B2B prices. If it were in Magento, those calculations would probably always be somehow intertwined. This kind of separation allows different teams to work on various cases, even if they are connected at first glance.   

Easy Magento update   

This matter is rather simple to explain. If there is no custom code in the core of Magento installation, then it is easier to update it to a newer version. This allows us to quickly deliver security updates and spend less time on that process. Adobe can promise many things, but custom-coded Magento will always be a real problem to keep up to date with the newest versions.    

Fewer 3rd party extensions – fewer problems   

A similar problem is solved in regard to 3rd party extension – so-called external vendors. Moving as many functionalities as possible to microservices removes some popular extensions from equitation, and as the old saying goes, “less external code in the core, fewer problems”.   

But where is the problem?   

There is never an ideal situation – so even if we tried to create such an implementation of Magento, we would quickly find problems. A simple shop with a small amount of custom business logic would be possible to build in this way. However, whenever we have more and more options coming into play, it adds more complexity to the original Magento build, making such a black box very hard to maintain.    

Let us just throw in a mix of new, more complex attributes to sort or filter. Suddenly, it becomes increasingly harder to move such code to external services, and we end up extending core functionalities. And this is just a simple example of how it can get worse once we dive into more complex business logic.   

This solution is also very quickly revised when we need to build promotions or use Adobe Commerce functionalities like, e.g., content staging. Those things are hard to maintain from external sources and require logging into the platform. All of a sudden, the idea of such a black box that is a mystery to the client becomes problematic.   

So, is it a good idea?   

Once again – such a solution is possible, but the answer to the question: “is it a good idea?” is not simple. Striving to create such a perfect solution might help make a complete and good build, but this mixture might be a very jarring experience.    

In the second part, we will analyse a real-world example of such a build and how we can solve some of the problems highlighted here. Meanwhile, if you want to learn more about what technology solutions we can provide for your online store, check our offering page.