Loading Form...
Aug 7, 2020 | 6 minute read
written by Linda Bustos
Composable commerce solutions, unlike a single-core, full-stack commerce platforms, consist of a portfolio of smaller applications which may come from multiple vendors, but play nicely together through APIs and the orchestration layer that supports them.
While all pieces of a composable platform are essential to the customer journey, individually they can be swapped in or out at any time, preventing vendor lock-in for any given capability. This ensures today’s “platform” is future-proof, that only components that need to be ripped and replaced are updated, and the system never requires a costly, time-consuming and risky full-stack upgrade or replatform ever again.
For many ecommerce applications, “going headless” is the first baby step towards a flexible architecture. Decoupling the front end from the backend frees the business from the restrictions of an ecommerce platform’s limited front-end capabilities, and ensures front end developers can work independently from back end teams without cross-functional coordination and introducing risk to an already fragile and bloated monolith.
Headless commerce also enables best of breed front end experiences, whether delivered through enterprise-grade content management systems and digital experience platforms (DXPs), or through mobile-first frameworks like React, Angular, Vue and Ember to power lightning-fast single page applications (SPAs) and progressive web apps (PWAs).
But “Headless 1.0” can only provide slicker desktop and mobile commerce experiences. It lacks the freedom and flexibility to extend to “commerce anywhere” touchpoints like mobile apps, connected devices, chatbots, voice assistants, social networks or Internet of Things without rock solid APIs (and not all commerce APIs are created equal).
And while APIs can technically connect commerce applications to new touchpoints, if the underlying platform is still a full-stack engine, “API-driven commerce” remains limited by the business logic and capabilities trapped within the monolith.
The next step beyond headless commerce towards ultimate flexibility involves adopting technology that embraces not one or two, but all MACH principles. MACH stands for Microservices, API-first, Cloud-native, and Headless.
Microservices
As discussed in our section on Modular tenet of Composable Commerce, microservices and are discrete “building blocks” of backend applications built around specific functions or business capabilities (Gartner refers to such microservices as packaged business capabilities” or PBCs).
Microservices are inherently composable thanks to their independent deployability and interoperability through well-defined APIs. This allows IT leaders to select the best “tool for the job” at any time, and add, remove or upgrade individual components as needed without compromising the full system.
API-first
API-first means an application’s business logic is configured through APIs rather than built into the service code. This eliminates technical debt within the commerce platform, and supports unified logic across multiple “heads” beyond the online storefront, such as virtual catalogs/lookbooks, mobile apps, voice commerce, IoT, chatbots and back office dashboards.
API-first design is not only flexible, but more efficient. New touchpoints can be added or removed at any time without compromising code or requiring full system downtime. Eliminating channel silos and duplicated development efforts accelerates time-to-market and ROI.
However, API-first is not to be confused with modernized commerce platforms -- monoliths that have an API layer added to the application. While this is a start towards flexibility, these APIs are often not granular enough to support the degree of business specificity and extensibility that truly modern, technically mature organizations desire. Commerce APIs may also be poorly designed, lack maturity or lack API coverage. Or, they may be overly granular and complex and come with a steep learning curve, which can slow down development and deployment. The more numerous, the more complicated to stitch together (and the more “chatty” API traffic will be across the application).
The sweet spot is the combination of clean, simple API design that supports any and all business requirements.
Cloud-native
There’s a difference between an application hosted in a public cloud and one built cloud-native from the outset. While a SaaS vendor’s monolith may be able to scale with demand on AWS and receive seamless updates, it must scale as a whole (including the database). What’s more, full-stack platform vendors can’t take advantage of agile code delivery like microservices-based commerce service vendors can, meaning “seamless updates” are fewer and farther between.
In contrast, microservices and PBCs are always built cloud-first, whether developed in-house or delivered as-a-service from a vendor. Not only do cloud-native composable components enjoy limitless scalability and resilience (failures can be moved around the cloud as workloads change) they’re also more secure. Because microservices can be independently deployed to a private network within a public cloud, attackers can’t easily compromise the entire system if they gain access to one component.
An added benefit to cloud-native SaaS applications is on-demand consumption. No need to deploy your solution, you can subscribe or unsubscribe to modular capabilities as you wish.
Headless
Like cloud-native applications, to qualify as truly headless an application must be designed as such from day one, rather than decoupling the head and slapping an API on the side. This supports interoperability between components and compatibility with any front-end or touchpoint.
Microservices and PBCs are headless by nature. But when composing an end-to-end commerce solution comprised of multiple applications from multiple vendors including content management, search, payments and PIM (for example), choosing headless applications such as Contentful, Acquia and Stripe amplifies your technical flexibility.
Javascript, APIs and Markup put the JAM in JAMstack. Like MACH for the back end, JAMstack is a modern architectural pattern for building front-end applications.
And similar to the concept of headless commerce which separates the front end from the backend, JAMstack separates the front end presentation layer once more, this time from dynamic functionality within the “head” application. This supports lightning-fast performance and optimal customer experience.
How?
Markup refers to your static HTML files (typically your templates). In a headless environment, these files may come from your static website generator like Gatsby, React, Vue or Angular, or advanced CMS / DXP. Because these files are static, they can be pre-rendered from a CDN cache so users see content as soon as possible.
However, many components of ecommerce are dynamic -- think price, promotions, inventory availability, average star rating and product carousels. With JAMstack, Javascript dynamically inserts content after essential markup, while APIs pull relevant data from back end services.
Headless commerce and JAMstack in practice
For example, you may be using a powerful CMS such as Adobe Experience Manager to serve product pages, but rely on your backend commerce service for pricing. Because price is dynamic (due to promotions or personalization) and needs to be loaded every time a user requests a page, the CMS server typically must render and serve the entire page rather than leverage caching, resulting in slower page load performance.
With JAMstack architecture, Javascript is embedded in the page where price lives, enabling caching of static content on high-speed edge servers and client-side rendering of dynamic pricing with page markup.
You may notice, JAMstack shares some properties with MACH -- decoupling of static and dynamic content, reusable APIs rather than app-specific databases, and cloud-hosted files through the content delivery network. Every time the front end is updated, files are added to the cloud-native CDN automatically, without having to write to a database. This supports front-end development agility.
Are MACH and JAMstack enough for Composable Commerce?
In this Composable Commerce series, we’ve explored modularity, openness and flexibility through MACH and JAMstack, but that only gets your business so far. To succeed, IT and Business teams need the ability to cooperate on large projects and digital transformation, and also leverage composable technology to support business users’ day-to-day activities (business-centricity).