What the Salesforce B2C Commerce API Launch Means for Retailers & Brands

This guest blog post was written by John Duncan, founder and CEO of 64Labs. As a web implementation services business, 64Labs implements proven, trusted ecommerce solutions for major companies worldwide.

The new B2C Commerce APIs are a flag in the ground for Salesforce. It is a statement of intent. It says that Salesforce will allow the front-end to be a thing on its own, and that the future of retail is headless. 

So what led to this?

I remember a major client  – 1,000 stores nationally, I think they were on Websphere – five years ago asking us how many developers we were putting on their mobile project. When I told them they would have three of our best front-end developers, all 10 year javascript veterans, they asked, “Okay, but how many real developers?” 

It wasn’t long ago that front-end on ecommerce was just window dressing and the developers who worked to build it were just the painters and decorators. The ‘hard’ work was done on the backend where real developers worked in the Java coal mines and sat around glass encased beige boxes flashing lights that pumped out morse code that translated to everyone outside their team as “difficult and important.” And slow. Really slow.

The ecommerce platform was a slow-moving, well-maintained cruise ship, which was fine because the seas were pretty steady and the ports of call were well known.

The problem was that as businesses demanded more and more of those front-ends – more reviews, more analytics, more images, more promotional content, more viewports, the experience that those templated platform-provided front-ends delivered simply couldn’t do a very good job for the people who mattered most: the customers trying to buy things.

The revolution started on mobile 

Mobile was the first battleground about 10 years ago. As marketers demanded mobile sites, and IT teams told them it would take 18 months, the first seeds of the liberation of the front-end were sown with external vendors (Mobify among them) crafting the first storefronts semi-independent of the ecommerce platform and solving an urgent business problem. 

This battleground has persisted ever since, between backend engineers who want to (understandably) move slowly and cautiously knowing that single errors can bring down entire operations and cost millions of dollars, and front-end teams who need to respond to the daily ideas of the business and the rapidly changing whims of customers. Meanwhile there was an explosion of Javascript-enabled front-end engineers to build functionality in a fraction of the time the backend guys were willing to even think about it.

A split was inevitable.

Google provided the tipping point

It was in the end Google who provided the tipping point. Or rather two of them. Unhappy customers landing on slow sites from search had revenue implications for Google. This prompted them to define some standards (Progressive Web Apps) and push tools (Lighthouse) that have nudged ecommerce operations towards at least thinking about what goes into making a great front-end experience for users.

The conclusion by most has been that what it takes to build a great backend – reliability, security, familiarity, resistibility to human error – is the antithesis of what it takes to build a great front-end – super fast, technically modern, flexible to novelty and change. Front-ends can risk more because reverting to a prior front-end can be achieved in a matter of a minutes if something does actually go wrong.

It is not surprising that Salesforce Commerce Cloud (formerly Demandware) spotted this trend quickly and have moved to get in on the act. It was Demandware who made their business in the last wave of backend change as incumbents sat back and assumed that putting ecommerce in the cloud would be too high risk for their customers while Demandware, with a solid product and great marketing, stole chunks of the market from them and proved them wrong. Ecommerce people are not as conservative as incumbents sometimes think. 

In the end, for ecommerce people, opportunity trumps caution.

Why should you care about Commerce APIs?

You should care about Salesforce’s new B2C Commerce API offering because it enables you to meet Google’s newest standards faster than your rivals – and meeting those standards will make and save you money. 

How does it make you money? It makes you money because it enables you to deliver a super fast experience, which multiple sources believe (with varying degrees of plausibility) translates to more sales in its own right. While I believe this to be true to some extent, it was hard to prove. And things that are true but hard to prove look like they might not be true.

That calculus changed in May 2020 when Google signaled and re-signaled that specific metrics will factor into search signals around the start of next year. Hitting the marks required to get top scores on their Core Web Vitals will require a modern, fast storefront, which old school reference architectures won’t do well at, but which new API-driven front-ends make possible.

A separated front-end, what gets called a headless approach to ecommerce by some and composable commerce by others, is going to be everyone’s unavoidable path to competing in search.  And, as in all things Google, those who get there first do best.

The problem with “headless” is that the “head” is actually a necessary part of the body. 

The “head” of headless can be risky

Salesforce’s headless path leaves customers with a small problem. How do you make it affordable for ambitious retailers to move fast on the front-end without taking unacceptable levels of risk around cost of ownership or project failure? 

That’s where Mobify’s development intersects Salesforce’s. Mobify had been on the cutting edge of PWAs for four years. 64Labs built our first PWA with them back in 2016. But it was becoming clear to Mobify a couple of years back that PWAs were not a mobile thing, but a front-end thing, and that meant that an architecture and framework needed to solve problems across devices. 

64labs built out our first responsive Mobify PWA storefront for a Canadian retailer on Salesforce Commerce Cloud in mid-2019. 

A year later and the framework has gone through the grinder of real-world usage, and the implementation methodologies have improved substantially. Now it really is possible to build out a Salesforce API-driven site on Mobify in eight weeks.

The good news is that this new world meets everyone’s needs and lets everyone do what they are best at. It works for Salesforce – they don’t have the headache of keeping up with the pace of front-end change. It works for Mobify – four years of building the infrastructure of PWAs and modern fronts-ends has found a purpose. It works for 64Labs – the skills we have perfected on the front-end for the past 7 years are suddenly in demand.

What’s in it for you?

Which is fine and dandy as long as we can answer one critical question: Does it work for you and your customers? 

Why should you want to go headless on a platform that has serviceable reference architecture on board for free? Apart from just the money that search optimization brings.

The first answer to that question is flexibility. You should want a headless approach with Commerce Cloud because it means you are now free to pick and choose vendors for reviews, content, personalization – in fact anything that has an API – and not depend on the Salesforce implementation as the limit of its functionality. Building a suite of functionality that works just right for you and implementing it in ways that offer a competitive (or cost) advantage is a welcome opportunity to compete in a highly commoditized ecommerce environment.

The second is omni-availability. With an API-driven build you can now use Commerce Cloud to drive non-web and non-traditional applications from in-store to native apps. 

And why Mobify as the front-end? My answer is one that might seem somewhat dull – reliability and infrastructure. Building your own front-end is viable. It is the right answer for teams who have capable javascript application engineers in-house and in abundance. And an experienced DevOps function. And who want to set up hosting and caching, and enjoy talking about routing and SSR strategies.

But that isn’t very many of us. What Mobify brings to the table is a starting point that isn’t a template, but which does allow you to take advantage of the experience of a platform maker in decision making and tooling. Mobify sites can be built quickly and supported internally. They enable all the benefits of headless like Core Web Vitals compliance and front-end development acceleration, but they strip out a lot of the hassle. We have seen V2 of Mobify’s storefront – which includes server side rendering and a GraphQL layer – deliver sites that had Lighthouse scores of 5 on SiteGenesis turning into scores in the 70s, 80s and 90s.

Mobify and 64Labs are offering all Salesforce B2C Commerce customers an 8-week path to headless on Commerce Cloud. Learn more about our Headless Commerce Accelerated program and get in touch if you’re interested in moving to a modern approach to ecommerce. 

Leave a Reply

Notify of
Resource ad

Related Articles