The commercetools extensibility features you must know

Care to share?

I was pretty surprised with the conversation that burst out on Twitter after my recent post about building Reliable JAMStack eCommerce applications. The discussion circled the still-existing need for customization, even when building the user experience from cloud-native building blocks. 

I totally agree. Things get more complicated when you start looking into the details. The product listing page needs to be integrated with stocks and there is this dynamic pricing tool – based on the user profile on top. Then we need to integrate the customer account with the recommendation engine. I can multiply the examples.

Actually, customization is a very important part of any eCommerce site creation. I like how Matthias Zielezny, head of software development at Marc O’Polo put it: “There’s an important distinction between systems you own vs. the ones you just use”. Pointing out that the systems you own and customize should be all around the User Experience and the business model – let’s see what you can do with commercetools extensibility features.

How can cloud-native platforms be customized? 

If you use Azure or Amazon Web Services for building your applications, you’ll immediately answer that, usually, when building a custom application using these services, you rather compose than customize. So you’re building a separate application or serverless function that lets you process the data, or insert/update the data from multiple other services. This is what I learned from Matthias. In the Marc O’Polo architecture, they build a pretty solid custom backend that is in charge of pushing and pulling the information between the eCommerce platform and all the other systems. Makes perfect sense.

However, when I’ve asked Halil Koklu of Lovecrafts how they approached this challenge he gave me some unique examples of how the commercetools platform let them modify the way commercetools solutions work, even to the extent of adding custom features to the admin panel.

I was impressed. I suppose commercetools extensibility features can be a role model for other API-first platforms. Let’s dig into some details!

Custom data model

One of the coolest features of commercetools is a very flexible data model. The platform itself uses MongoDB as a backend

MongoDB as a backend
commercetools data model

Products have multiple types, variants and can be assigned to multiple categories. Moreover, there’s virtually no limit on defining the custom product attributes. The attributes can be configured out of the many different data types including numbers, text, enums but also references to other objects and JSON documents. All of these properties are subject to search and filtering features. To be honest – I’ve rarely seen such flexibility in managing the product catalog: impressive even as for professional PIM systems.

Moreover, the products can be bundled together using the Bundle API with all possible types of grouped, configurable, and custom option product configurations.

One important feature worth mentioning here is the IMPEX – import and export tools. IMPEX lets you execute partial or full imports of the product catalog, attributes, variants, stock with any combination of those – which is actually great for modeling even pretty complex data exchanges between third party services and eCommerce platforms themselves.

Custom Applications

This is a pretty unique feature of commercetools. Developers can extend the admin panel (Merchant Center). To do so, there’s a boilerplate application and set of CLI tools to streamline the process. You can use the ready-made UI kit to make your application aligned with the other parts of Merchant Center. 

What’s really cool though is that the way Custom Applications are deployed is 100% aligned with the decoupled/microservices concepts commercetools is relying on. I mean the applications are really separate JS/TypeScript apps, compiled – deployed to Amazon Web Services/Vercel/Firebase and only then being loaded by the Merchant Center. It’s like MC is just loading the React.js application from the URL specified in the app manifest.

Then, the application itself is using just the REST or GraphQL API provided by the platform, fully secured and isolated from the users’ code.

Amazon Web Services
Custom Applications are aligned with the Merchant Center UI by re-using it’s UI Kit (design system) – still being bundled as isolated JavaScript Applications

API Extensions

Custom Applications is one of the features showing the general approach commercetools architects had in mind when designing the platform. Another can be API Extensions. I’ve spoken with Kelly Goetsch, commercetools CPO about it and he showed me how, by using just the serverless functions, one can modify, add and extend virtually any API call commercetools has under its belt.

It’s like a proxy that filters in and out the HTTP requests then processed by the API itself. Again, it’s not a module so it’s decoupled from the core platform and fully isolated.

With this attitude, a very high SLA and out-of-the-box functionality provided by the platform in the SaaS model is not colliding with the flexibility of custom extensions.

Subscriptions

Another cool feature is subscriptions. Imagine you can use the Amazon SQS or Azure Service Bus to emit all the changes taking place in the eCommerce platform? Out of the box in commercetools. It’s a great feature for integrating the systems and responding to the events like new orders, stock reservations and so on. 

Custom frontend and channel applications

The last but not least customization features are of course the custom front ends. It’s not limited to the mobile/web front ends as you can build with Vue Storefront. Think Voice Apps, IoT. There’s all set of the REST and GraphQL APIs to be consumed from commercetools SDK.

commercetools extensibility features – wrap up

Most of the headless eCommerce platforms offer customization features to some extent. I suppose the most important part here is actually that with the API-first and headless commerce solutions you’re no longer >customizing< the platform. You’re building the apps that actually >do use the platform< along with many different services. The role of the eCommerce platform changed significantly. With this approach in mind, developers are no longer limited because everything starts with their scope and invention so they can choose to change or mix many different features of different applications: altogether. Something that was virtually not possible before.

Want to know more about how you can boost your eCommerce with commercetools? Read our article about global rollouts – part 1 and part 2.

Published December 16, 2020