This piece goes over the functional aspects of that patent and why you’d want a platform that sits in the cloud like us, instead of on the cloud.
We at commercetools are proudly in the cloud as a first class service, not on the cloud. It’s a defining feature of our platform. With the issuance of patent 10,747,600 last week by the US Patent and Trademark Office, we now have legal protection for the intellectual property we’ve developed that keeps us in the cloud.
On the Cloud
Every commerce platform requires customizations (changing how an out of the box feature works) and extensions (adding new functionality on top of the platform). The vast majority of the cost and complexity of an implementation is in the customizations and extensions.
All of the major commerce platforms have these extremely opinionated extension frameworks. Because they were all built pre-public cloud, they are deployed to public cloud in virtual machines that are not capable of interacting with the larger cloud ecosystem. Though Salesforce and Magento are deployed to AWS behind the scenes, you as a developer would never know because you’re essentially working with an application deployed to a locked vault (a VM with its own private network).
The problem with this approach is that you have to hire extremely specialized developers who deeply understand the commerce platform they’re working with. Think of these developers as brain surgeons who need to know exactly where to make changes. The big commerce platforms on the market easily have 5 or 10 million lines of code, so they tend to be very complex. You have to know exactly how to send an email using their framework, or how to add a custom inventory check. Speaking from personal experience, it’s hard! That’s why traditional commerce platform implementations take so long and require so many specialized people.
In the Cloud
We at commercetools were built natively in the cloud, for the cloud, from day one. We launched our platform in 2013 just when cloud as we know it today really started to take shape, so we were able to leverage cloud-native architecture patterns and technologies. We event data out to the message queue of your choice (Google Cloud Pub/Sub, AWS SQS, Azure Event Grid, etc (every time a product is updated, order is submitted, etc). Since events are the common bus between cloud services, you could send the customer a “Thank you for your order” email via AWS Lambda, or feed the data into GCP TensorFlow for input into a customer loyalty-related Machine Learning algorithm. In commercetools-world, we call this a subscription. Many of the customizations and extensions required, especially passing data between systems, can be accomplished using this approach.
But what about synchronous events? That’s the patent that was granted today. Our Extensions functionality allows you to call out to serverless functions synchronously at multiple points for every call in to commercetools and with every response out of commercetools.
As a quick example, let’s pretend you sell luxury jackets. Before you allow your customers to add a jacket to the shopping cart, you want to make sure you actually have it on hand in a warehouse. Allowing a customer to add a product to the cart and then being told it’s unavailable during checkout is a poor customer experience. With the newly-patented Extensions functionality, you can now pass the API request body to a serverless function or to an arbitrary URL (backed by a microservice).
In this example, a little AWS Lambda function can check the warehouse management system (WMS) in real-time. If the jacket isn’t actually in stock, the customer can get an immediate response and be prompted to select a different one.
By being unopinionated, we allow developers of all skills to contribute.
We’re the very first commerce platform to be a native first-class citizen of cloud. Check us out by creating a free 60-day trial.