Get to Know Headless Commerce

Learning Objectives

After completing this unit, you’ll be able to:

Define headless commerce.
Discuss the difference between a headless and traditional approach.
List three advantages of using a headless approach.

Introduction

Vijay Lahiri is a senior developer at Cloud Kicks, a company that specializes in high-end custom sneakers. He’s heard about a new architectural design approach called headless commerce, which separates the shopper experience layer of an ecommerce site from commerce services.

Vijay Lahiri, Cloud Kicks developer

His fast-growing company is hiring many new developers to accommodate the accelerating changes and innovations in ecommerce. As the world becomes increasingly connected, he hopes the headless approach can help his team deliver more personalized experiences a whole lot faster to Cloud Kicks shoppers on a wider set of touchpoints.

Traditional Commerce Approach

Many companies like Cloud Kicks use legacy commerce platforms with a traditional approach that supports complex, tightly coupled software on monolithic systems. Feature changes can mean editing databases, updating system code, and customizing the front-end platform. To make a single customization, Vijay and his team often edit multiple layers of code from the front end to the back end. Because changes affect multiple areas, Vijay and his team also spend a lot of time testing and troubleshooting. Some changes can actually void support contract warranties or prevent future upgrades.

The development team is so busy with the day-to-day tasks and shifting priorities that innovation often gets lost in the shuffle. Even though the Cloud Kicks storefront application has plenty of customization features and unrestricted access to code—not to mention an expanding development team—it’s designed to deliver content only in the form of websites or mobile apps. The Cloud Kicks marketing team wants to expand their offerings to other devices as soon as possible.

Salesforce B2C Commerce

Cloud Kicks already uses B2C Commerce, a software as a service (SaaS) platform that’s fully cloud hosted. Salesforce manages all the work related to database maintenance, security patching, and other infrastructure and operations work that has traditionally cost companies like Cloud Kicks a lot of time, attention, and money. Because Salesforce seamlessly updates B2C Commerce many times a year, innovations such as Einstein artificial intelligence (AI) and Page Designer (a drag-and-drop declarative editor) are regularly made available. Salesforce offers reference architectures with a lot of flexibility, but changes can still impact the back end and the front end. Moving to the headless architecture gives Cloud Kicks greater flexibility.

Developers like Vijay can build all sorts of customer experiences with the developer tools included with B2C Commerce. Vijay learned all about these tools in the Develop for Salesforce B2C Commerce trail. These tools, including RESTful APIs and more, give Vijay everything he needs to develop experiences using a headless architecture. Before he gets into the details about these tools, he wants to learn more about headless commerce.

What is Headless Commerce?

Headless commerce is where the content (product, prices, text, and graphics) is stored and then delivered without a front-end layer. The front end (or the head) is decoupled from the back end and APIs bridge the gap, delivering content like products, blog posts, or customer reviews to any screen or device. Front-end developers present fabulous content using a framework that best meets their business requirements.

Manage and store content on the back end, then connect to any channel on the front end via web APIs.

The front end of an ecommerce site represents the shopper experience, including everything that shows up on the storefront, such as product details, graphics, and promotional content. The back end represents the business processes resulting from the shopper experience, the commerce services supporting it, and the data underlying it, such as search, promotions, pricing, inventory, and checkout.

For example, say a shopper buys certain products that trigger a promotion. The shopper selects products by size, color, and price (front-end), and then a business process identifies qualifying promotions (back end and API) and displays the information on the shopper’s device (front end).

The front and back ends operate independently so that changes to one don’t require changes to the other.

Why Headless?

The headless commerce architecture bridges the gap between the front end and the back end with APIs, along with a back-end data model and cloud-based infrastructure. With this model, Vijay or a web developer can use any front-end tool to deliver customized content, products, and payment gateways to applications such as smart watches, kiosk screens, and Alexa Skills.

Just as there are lots of ways Vijay can implement headless commerce, there are lots of reasons he wants to.

He can...	By...
Increase feature rollout velocity	Separating front- and back-end change requirements.
Widen technology scope	Making independent technology choices for the front and back ends. Using industry standard tools and components. Accessing a wide spectrum of code-based development tools, connectors, and APIs for speed and flexibility. Combining best of industry tools for both ecommerce and content management systems. Using commerce-friendly APIs and tools for heavy site customization and personalization.
Integrate more	Building quickly with certified pre-integrated back-end connectors from tax to payments and more. Mixing and matching commerce services and applying them to the right touchpoint, channel, or device.
Expect improvement on key metrics	Counting on improved website performance and SEO improvements. Increasing front-end portability to other devices such as mobile, smartwatches, kiosk screens, and IoT.

Faster Impact

Headless can mean significantly faster delivery of front-end changes, like updates to the storefront look and feel or improvements in how shoppers experience checkout or account management. With a headless architecture, as soon as Cloud Kicks pushes changes to its front end, the updates are reflected almost instantly. Thanks to the API integration, front-end innovations are independent of the back end. Compare this to sites built with traditional commerce architecture, where changes ripple more slowly through the publishing process before all shoppers experience the latest designs. Multiple iterations of replication and testing can slow things down considerably.

Seamless Viewing

With headless, merchants control the elements shoppers interact with more easily, and marketing teams can get more creative with the content they publish. Also, the universal compatibility of headless commerce ensures that websites work seamlessly and as intended across all devices and viewing formats. Managers of traditional ecommerce websites, on the other hand, must use responsive design or other techniques to minimize the risk of elements disappearing or displaying incorrectly across various devices. It’s just another testing task added to the list for developers using traditional commerce architecture.

Personalize the Shopper Experience

With headless commerce, merchants like Cloud Kicks can capture data and unify their entire customer journey. No matter which channel a shopper shows up on, the back-end system recognizes them. With a complete view of this data, the storefront application can personalize the shopper experience at scale with artificial intelligence (AI) capabilities, from the storefront to third-party front-end applications. Headless commerce enables merchants to find other ways to present their data on myriad touchpoints.

With headless commerce, shoppers are recognized no matter if the touchpoint is mobile, Alexa, desktop, or watch.

What are RESTful APIs?

Headless commerce can use RESTful APIs to connect and interact with cloud services. A RESTful API is a set of functions that perform requests and receive responses using hypertext transfer protocol (HTTP). HTTP defines standardized request methods such as GET and POST.

The beauty of this is that any programming language can use HTTP. What’s more, REST technology uses less bandwidth for communication than Simple Object Access Protocol (SOAP) technology, making it more suitable for the internet. Sites such as Amazon, Google, LinkedIn, and Twitter already use RESTful APIs.

Because RESTful APIs are stateless, the client and server (in this case, the front and back end, respectively) are required to be independent of each other. Either can be coded in any language for maintainability and easy evolution. RESTful APIs are one of many options in the headless commerce architecture.

How versatile is that!

Vijay can implement a custom checkout flow for multiple devices on the front end, and use the same RESTful APIs to communicate with the back end, whether he’s using a headless commerce architecture or not. The transition to headless commerce doesn’t have to be all at once. As he moves with his team into the headless world, he can maintain the existing fully integrated development approach on the production system, while developing new storefront capability with headless.

Next Steps

You learned a lot about the headless commerce front end, back end, and RESTful APIs. You explored the pros and cons of headless commerce and how headless can personalize the shopper experience across touchpoints. Next, you dive deeper into the who and how of going headless.

Looking for Help?

Discover More