Why U.S. Patent No. 10,747,600 Matters

We had our first patent issued last week and we discussed the significance of that for staying ahead and solidifying our name as an innovative company. 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.

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.

With every other commerce platform on the market, you must write all of that custom code according to the framework defined by your vendor. They are all opinionated platforms. Custom code runs within the platform, often wrapping the commerce platform’s code. For example, Salesforce Commerce Cloud requires you to use their JavaScript-based extension framework. If you want to extend their platform, this is the way you do it.

It’s an opinionated framework, to the point of dictating that you use the orphaned Rhino JavaScript engine (circa 2006), which isn’t capable of using all the fancy ES6 features you may find with Node or more modern frameworks.

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.

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 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.

Once you can change outgoing API calls and incoming API responses, you can change basically anything you want, with the key advantage being that you can do so using any programming language. AWS Lambda, for example, supports Go, Java, JavaScript, .NET, Python, Ruby, and more. Rather than having to hire commercetools developers, you can now just hire smart cloud developers. It’s a completely different paradigm. And now it’s patented.

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.