Part 1: The path to headless on Salesforce Commerce Cloud (SFCC)

As Headless Commerce gains momentum, we will outline everything you need to know when it comes to Headless and the Salesforce Commerce Cloud (SFCC) platform. We’ll explore this in two parts, first, the structure and infrastructure and second, the delivery and organisational structure needed to support a move.

Headless commerce and why it matters

Headless commerce refers to a decoupled frontend from backend in an eCommerce application. The ‘head’- decoupled frontend – communicates with the backend through a set of APIs. This differs from the traditional monolithic platforms where the two are tightly coupled and managed in one system.

Why does it matter?

Headless commerce provides businesses with the agility to build personalised customer experiences across channels faster and without dependencies on the backend infrastructure.

This approach to commerce enables organisations to drive innovation through speed of change and increase storefront performance by leveraging Progressive Web Application (PWA) capabilities – improving customer engagement and conversion rates.

How does Salesforce approach headless?

Salesforce’s acquisition of Mobify – a ‘frontend as a service platform’ – paved their path to headless commerce and helped fulfil their goal of providing customers with the platform and tools to deliver Progressive Web Application (PWA) experiences. As well as a hosting infrastructure which solves the problems of the traditional headless architecture of security, scalability and maintainability.

Salesforce focussed on a complete integration between the frontend platform and the commerce engine by leveraging Salesforce Commerce APIs, built on a new API-first platform. It comes with multi-tenant support, an embedded CDN layer in front of the APIs, as well as better support for wide variety of headless use-cases – from the customer shopping experience and the backend administration and operation of business processes. This integration is called PWA Kit and was officially launched in September 2021.

What is PWA Kit?

The PWA Kit is built on the React framework and offers a reference code base called ‘The Retail React App’ – a good starting point for building a headless storefront.

The Retail React App comes with the implementation of PWA Kit React SDK. This is the application’s backbone and provides an abstraction layer that allow developers to customise key classes, functions and components. Most importantly, the SDK provides tools and utilities which enable the rendering of JS code on both client and server side. The main benefit for developers is that they can create code which interacts with the platform through the Shopper APIs and can run it in both the browser and the Node.js runtime, which should also positively impact speed of change.

Although the app supports the new Salesforce Commerce APIs, it’s important to note that they are currently used for products, promotions, gift certificates and search services only. For baskets and orders services, the app still uses Open Commerce API (OCAPI), which differs from the new standard in many aspects – the API architecture being the most important. OCAPI will continue to be a supported product, but new apps and SDKs will be created using the newer Commerce APIs.

The reference application comes with a testing suite that includes unit and E2E tests built with Jest and Cypress frameworks. The app also comes with perfectly optimised stats for performance, accessibility and best practices as measured by Google Lighthouse. It’s important for developers to maintain these scores when customising the app, so a Lighthouse Performance test is also part of the testing suites.

Chakra UI is a modular component library that provides building blocks and theming options for the Retail React app. Most of the reusable components in the codebase could by styled with the theming capabilities of Chakra UI, but some of the dynamic pages like PDP and PLP would require changes to the inline styles.

Of course, the app cannot work without core technologies like Node.js, Express.js, Babel etc., but Webpack is the most important to note, because this static module bundler is responsible for creating code bundles which are being deployed to the Managed Runtime.

Managed Runtime

Managed Runtime provides a hosting infrastructure which enables deployment and monitoring of applications built with the PWA Kit. An added benefit of this hosting infrastructure is that it does not require an additional license or incur additional costs to customers who are already on Salesforce B2C Commerce.

Managed Runtime allows merchants to create multiple projects and environments within an organisation, as well as push multiple apps easily across different environments.

The apps are pushed to the Managed Runtime in a form of a bundle, which represents a snapshot of the code at a specific point in time. The bundles cannot be changed after they are created and pushed to the Managed Runtime environment. This provides an accurate view of all code pushes and ability to track and troubleshoot deployments.

It also comes with admin tooling which enables merchants to perform all operations described above – like managing organisations, projects, environments and bundles through two different options:

• The Managed Runtime Admin, a web user interface where merchants can login and configure settings, create projects and environments, deploy new code to an environment
• The Managed Runtime API, a REST API that offers the same functionality as the Managed Runtime Admin, but also provides additional capabilities which enable digitally mature organisations to implement CI/CD strategies

Of course, the Managed Runtime does come with an app server, which is a combination for React, Node.js and Express framework. It runs on a serverless technology supported by several edge services which are distributed through the Salesforce public cloud infrastructure and are located as close as possible to the user location.

The services include a web application firewall to prevent hacker attacks, a proxy server for optimised performance of the API requests, a content delivery network which enables caching of requests and better page performance, as well as edge functions which process requests and handle redirects.

This article describes in detail the configurations for the proxy server and the CDN.

For further information on the path to headless on SFCC, check out part 2 of our blog. Our experts will provide insight on delivery and organisational structure needed to support a move.