API-first or Dressed-Up Middleware

How to Know if Your Commerce Platform is Truly API-first?

In case you missed it, last week I covered what it means to be API-first, and how that’s different from a code-first approach. In this piece, I’ll write more about what API-first means for commerce, and why it’s not as hard to implement as you may think.

The lingua franca amongst commerce vendors in 2022 is composable and API-first. It’s why I invested in Moltin years ago and why I joined Elastic Path in 2020 to run the product team. There’s a foundational shift in how modern software is built and consumed. First software ate the world, then a16z’s Martin Casada highlighted in 2017 that world is now available through an API.

Given that “ecommerce” is a well established market, there are a lot of legacy systems masquerading as API-first, bringing along all their complexity for the ride. One can “API anything” – but, in doing so, one does not become API-first.

When considering a new commerce technology, potential buyers should understand that API-based platforms generally come in two forms:

• API-first approach: Cloud-native APIs built from the ground-up to simplify communication between systems to facilitate rapid-cycle application development. Stripe is a great example here.
   
• API-secondary approach: Legacy monoliths that have refactored existing architecture constructs and capabilities to make them available via APIs but bring all the complexity of the legacy architecture along for the ride. Most of the companies I worked for in the first decade of the 21st century come to mind here.

The benefit of an API-first approach is that the APIs are lightweight and can be designed to be easily extended to serve a variety of specific use cases. For complex use cases, it’s possible for developers to design these APIs to communicate with one another and streamline requests that pull related data in. This approach removes a lot of the complexity that comes with a disassembled monolith.

Legacy monoliths, on the other hand, offer a broad spectrum of APIs to serve a myriad of use cases. While that comprehensiveness may seem appealing at first, it drags along all the complexity originally designed into the monolithic architecture. Refactoring does not eliminate complexity; it simply presents it via new interfaces. As a result, we often see vendors tout their support for tools such as GraphQL as a benefit, when in actuality, a separate orchestration layer serves to combine their many disparate APIs into useful functional requests.

Let’s get into these two issues a bit more.

See How Elastic Path Delivers Unique Customer Experiences

The Elastic Path Demo Library features multiple demos that showcase the power and scale of our products.

Simplified Request/Response

Elastic Path Commerce Cloud was purpose-built for the singular function of supporting commerce applications powered by the catalog. That means the request/response model works seamlessly, abstracting away unneeded complexity behind the scenes, rather than surfacing it all for the developer to navigate. For example, a single call is designed to return all the information needed to support building a product details page. An API call for this purpose would return:

• Full product details and attributes, including custom and product-specific details.
• Situational pricing, such as rules for a specific channel, customer or other rule-based pricing. For example, a northeast price book vs. a southwest price book can be automatically returned based on request parameters.
• All available product variations and options, as well as the mapping of those options to the specific child product for adding to cart. This includes all possible iterations of sizes, colors and SKUs.
• Availability information.

The Elastic Path Commerce Cloud REST APIs have only four ways to interact. For example, following REST standards:

• To create a product, the products endpoint is called with an HTTP POST request
• To retrieve, a GET is called
• To update, a PUT is called
• To remove, an HTTP DELETE is called.

To contrast, in monolith conversions, there could be dozens of actions required to be called to perform those four simple functions to manage a product. Because Elastic Path Commerce Cloud is built with commerce product information in mind, following REST standards keeps it simple. That way, developers can focus on building out the specific business value instead of navigating the many dozen actions a monolith conversion may require.

No Need for Separate Tools as Intermediaries

As mentioned above, monoliths with hundreds of discrete APIs need orchestration, and will often require a tool such as GraphQL between the APIs and the front end. This is not the case with an API-first platform like Elastic Path Commerce Cloud. Additional orchestration tools are required due to the under-fetching issue common among monolith conversions. By mapping the various APIs to GraphQL and using the query language to combine many APIs together, developers have to do a significant amount of work to get the same result available in a single Elastic Path Commerce Cloud call.

It’s important to consider the performance aspect of this issue. Think about adding a GraphQL call to the backend APIs that then respond to GraphQL, and finally GraphQL responds to the initial request. This adds latency and degrades performance, where Elastic Path Commerce Cloud allows you to call your APIs directly by combining related data into a single call.

Consider the following common extended API use case: a customer wishlist. Normal REST APIs would require several API calls to get the customer data and wishlist items. With Elastic Path Commerce Cloud, the customer API can be extended with a “one to many” relationship to products that are on the customer’s wishlist. Then, a single request of the customer record can be made that does not “include” the products in the wishlist. Or, if the endpoint is called with the query string include=wishlist_products, all of the products on the wishlist will be returned. This avoids the need for an interstitial tool such as GraphQL.

Abstracting Away Complexity with API-first

To sum it up, API-first commerce platforms like Elastic Path Commerce Cloud can make it much simpler to take advantage of the flexibility and combinatorial power of the API economy. It doesn’t have to be difficult to assemble a platform of components that create competitive differentiation for your commerce experiences. Or your team can focus on building custom components that matter most to your customers. Regardless of your strategy, to avoid legacy baggage and complexity, API-first is key.