Headless vs Traditional eCommerce Platforms: Introducing Commerce Layer


In this lighting talk Fabrizio will go through the main highlights of CommerceLayer, comparing the headless approach to the traditional "monolithic" ecommerce platforms. We will speak about security, performances and scalability.


Hello everyone, my name is Fabrizio and I'm the partnership manager of Commerce Layer. What is Commerce Layer? Commerce Layer is an AdWords Commerce platform and an order management system. And thanks to its AdWords nature, the idea is that you can pretty much add global shopping capabilities to any sort of user experience you have in mind. So it could be a website, it could be a mobile app, a chatbot, it could be a video, actually you name it. And all of these in a very, very simple and effective way.

So as our product is an AdWords Commerce platform, of course the core of Commerce Layer is its api. So we offer a quite extensive range of endpoints to manage all the different aspects of the commerce experience. So prices, shopping, cart, inventory, orders, and so on. So unfortunately I cannot go through all the lists of the endpoints, but you can find them in our documentation. And I think it's important to stress the fact that Commerce Layer is an AdWords platform. And this is very true if you compare it to the traditional monolithic solution. So I guess you already heard this term, a monolithic platform, but what does it mean?

Actually, it means having a single platform managing all the features of your e-commerce application. So think about the platform that actually manage everything. So it manages the CMS, the product information management, maybe the order management system, everything in just one single box. These unfortunately come with some challenges and we try to summarize them in five main points. The first one is that such platforms are actually less flexible. Why? You have to think that you have just one single box where everything is implemented. So this means that you can't change any module of your application or your commerce application without actually replacing everything. So this is quite a big problem. So if new needs emerge in your business that might require, I don't know, maybe a new model or a new application, let's say your platform won't allow that without a full re-platforming. So you can imagine this is quite a big problem.

The other problem related to these traditional applications is that most of the time the result is that the website build on top of those there are just as slow. Why that? That's because given the architecture of those applications, it's very difficult to leverage the power of new concepts like dedicated CDNs, for instance. And as you can imagine, a slow website can be a big problem, especially if you consider, I don't know, things such the new Google algorithm for ranking the core web vitals, just to make an example. So being fast is definitely a competitive advantage when you're selling online.

There are also security issues. If you have just one application and everything is inside that box, you have a single point of failure. So if that application fails, everything fails. This is a big problem. Other problem is that considering that these traditional applications are, let's say, have been designed quite some time ago, most of the time they were built for desktop. So they don't have a really, let's say, mobile first approach, for instance. And the last problem is that they are expensive. There is quite a lot in these boxes. Sometimes you don't need some of the stuff that is in these boxes, but you are anyway going to pay for all of them.

So what is the solution? Well, the solution is actually to work on architectures that are modular. And this actually means splitting the monolith. So these, for instance, can be, let's say, an example of a modular architecture based on commerce layer. So commerce layer would be the transactional engine, managing prices, stock information, checkout APIs, and customer account APIs. And around commerce layer, you will start integrating all the different services that are needed to deliver the commerce experience. So an Atlas CMS, for instance, a static site generator. This is very true if you are going the gemstack direction. A deployment platform to optimize and maximize the performances. And then link commerce layer to specific services for the needs that you might have. So tax calculation services, payment gateway, shipping carriers, and also the legacy system like the CRM and ERP. And what are the benefits of this approach? Well, as you can imagine, everything now is extremely flexible. You can swap in and out modules very easily without doing a full re-platforming. It's much easier because now you can scale just one specific module and avoid, let's say, very expensive upgrades of your central platform. So you can just selectively scale modules of your architecture. It's more secure because now you don't have a single point of failure anymore. And it's omnichannel by design because all of these modules actually has an api interface.

So you can connect pretty much everything, whatever touchpoint you think about to this sort of architecture.

And last but definitely not least is future proof. Being future proof actually relies on the fact that you can change whatever module depending on your needs without, let's say, doing a full re-platforming.

Thank you very much for your attention. And in case you have any questions, you can drop me a line at my email or just book a demo of our platform at commercelayer.io. Thank you very much.

8 min
10 Jun, 2021

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Workshops on related topic