Headless commerce is becoming an increasingly attractive option for businesses of all sizes. In a headless setup, backend and frontend code is completely separate and any communication between them happens via APIs . This “decoupling” offers a lot of flexibility. It allows the changes to be made to the storefront without risking errors in backend code, and vice versa. While the API-based approach makes it easier to connect different data sources to power your storefront.
Moving to a headless commerce platform means that you’ll need a way to build the frontend “head”. This article takes a look at a few of the most popular storefront solutions for headless commerce.
What does Alokai (Vue Storefront) do?
Alokai is a Frontend as a Service (FEaaS) solution for headless commerce that gives developers a set of tools to quickly build, deploy, and monitor ecommerce storefronts. Alokai provides foundational frontend infrastructure, along with prebuilt integrations and core frontend components that can easily be customized and extended to meet business needs.
The Alokai solution is designed to be technology agonistic when it comes to the backend, which means that you can power your storefront with data from any ecommerce engine, content management system (CMS), enterprise resource planning (ERP) system, or any other tool in your tech stack. Making Alokai particularly useful for companies moving towards a composable commerce architecture .
From VUE Storefront to Alokai
When we first launched our open-source solution back in 2017, VUE Storefront was a very apt name for what we offered – a headless storefront starter built with Vue.js. As our business evolved, however, it became pretty clear that we’d outgrown our original name.
On a very practical level, once we launched the React version of our storefront kit it just didn’t make sense to keep VUE in the name. Additionally, our offering has grown far beyond a simple storefront starter to a rich set of enterprise-ready tools to help developers quickly build, connect, and deploy composable frontends.
We wanted a name that better fit our product, as well as reflected our wider vision of helping companies navigate the transition to modern commerce architectures, so in 2024 we rebranded VUE Storefront to Alokai.You can read the full story about the Alokai rebranding here .
Top 4 Alokai alternatives
A headless commerce platform, by definition, isn’t locked to a frontend delivery method, but some vendors do provide both a headless commerce engine and a solution for frontend web development.
This is especially common if the platform was originally a monolith but now supports a headless setup, like Salesforce Commerce Cloud and SAP Commerce Cloud , as their customers have always expected a storefront to be available. While some natively headless platforms, like commercetools , have added a frontend offering to cater to merchants that want an out-of-the-box option to launch online stores.
This means that the decision on how to build the “head” for headless commerce usually comes down to:
Developing the custom frontend yourself;
Using the frontend solution provided by your ecommerce platform vendor;
Or using an independent FEaaS, like Alokai.
Here's a quick summary before we jump to the specifics of each.
Do you need Alokai or an Alokai alternative for your web development?
First off, the most simple answer – if you’re not planning on going headless , you don’t need a headless frontend solution.
When is it best to build a custom frontend?
When you have a team of very experienced developers and the time, resources, and desire to build frontend infrastructure from scratch.
When is it best to use the headless frontend solution provided by your ecommerce platform vendor?
If nearly all of your customer experience is powered by the vendor’s ecosystem, with minimal need for third party integrations or customization of the out-of-the-box storefront components, then it makes sense to use the frontend solution that’s being developed alongside the platform.
When is it best to use Alokai?
Alokai FEaaS works independently of any specific backend platform, which makes it a great choice for organizations that rely on a variety of platforms, services, and data sources to power their customer experience. Such as cases where:
You have a diverse tech stack and need to orchestrate data from a variety of sources.
Your organization works with multiple commerce platforms and you want to streamline frontend development across them.
You want to be able to switch your commerce platform in the future without having to rebuild the customer experience.
You want to start moving towards a composable commerce architecture .
Want to see Alokai in action? Here are 15 examples of companies getting ahead with headless commerce .
Frontend solutions for headless commerce | ||||
| Alokai Enterprise (VUE Storefront) | commercetools Frontend | SAP Composable Storefront | Salesforce Composable Storefront |
Supported commerce platforms | Any headless platform. With prebuilt integrations for commercetools, SAP, Salesforce, BigCommerce, and Adobe/Magento commerce platforms | commercetools Composable Commerce | SAP Commerce Cloud 2105 or newer | Salesforce Commerce Cloud B2C |
Technology stack | Vue.js/Nuxt or React/Next.js | React/Next.js | Angular | React/Express |
Frontend architecture | PWA | PWA | SPA | PWA |
Extensible API layer between frontend and backend | Yes | Yes | No | No |
Starter storefront available out-of-the-box | Alokia Storefront | Storefront launchpads for B2C retail & B2B manufacturing | accelerators* for financial services, telco & utilities, and citizen engagement | Retail React App |
Ease of frontend customization | High | High | Medium | Medium |
Ease of integration with third party solutions | High | High | Low | Low |
Primary use cases | B2C & B2B | B2C & B2B | B2B | B2C |
*These are Composable Storefront accelerators meant to replace the now depreciated Accelerator storefront templates.
With that in mind, let's see what's special about each option.
1. Custom build
With any headless commerce platform it’s possible to build a storefront from scratch using a frontend framework like React or Vue.js .
This gives you absolute control over your frontend, but it requires expertise in everything from frontend design to integrations to cloud infrastructure. It also means teams have to spend a lot of time and resources “rebuilding the wheel” before they can start focusing on the more unique parts of the customer experience.
Best for
Companies that choose to build their own frontend typically have advanced engineering teams and unique use cases or complex business requirements.
Pricing
The cost of a custom-built storefront can vary widely. It includes the investment in the initial build, hosting costs, and the ongoing resources needed for maintenance and security.
2. Salesforce Composable Storefront
Salesforce Composable Storefront is a frontend solution for Salesforce Commerce Cloud B2C , which is a commerce platform originally built with the backend code and frontend presentation tightly coupled.
Over the years, Salesforce has worked to modernize this architecture. First developing a mobile-first frontend framework for the platform, Storefront Reference Architecture (SFRA), and then a new API infrastructure, Salesforce Commerce API (SCAPI), that makes it easier to integrate Salesforce commerce functionality with third-party systems and frontend frameworks other than SFRA – aka, headless.
Composable Storefront is an alternative to SFRA. It's a set of developer tools to build and deploy React-based storefronts that talk to Commerce Cloud exclusively through SCAPI. It’s based on technology that Salesforce acquired from Mobify, a FEaaS provider, in 2020.
Key features
Progressive Web Application (PWA) kit: The PWA kit is used to build a frontend with React. It includes a customizable storefront, the Retail React App, and a Chakra UI component library to help developers get started.
Managed runtime: Managed Runtime provides the infrastructure to deploy, host, and monitor your PWA kit storefront. Including a serverless hosting environment, using AWS Lambda, and a Content Delivery Network (CDN) for caching and distribution.
Hybrid storefronts: To help companies transition from SFRA to Composable Storefronts, Salesforce provides guidance on how to implement a hybrid storefront where some pages remain on SFRA templates and other parts of your website run as a PWA.
Salesforce CC limitations
Only compatible with Salesforce Commerce Cloud B2C implementations.
Doesn’t provide a separate API layer to orchestrate data, but uses individual proxy API calls to different backend applications. This makes it challenging to work with different data sources, as you have to coordinate multiple API calls which can slow down site performance and makes it hard to maintain and scale the frontend application.
Best for
Composable Storefront is likely most attractive to companies that already use Salesforce and want a hybrid setup, where they use a PWA for parts of the website that are frequently updated and keep the rest on SFRA.
Notably, Composable Storefront is only for Salesforce Commerce Cloud B2C, the former Demandware platform. As the Salesforce product for B2B/D2C commerce has a completely separate architecture, built on top of their flagship customer relationship management (CRM) platform, and does not use SCAPI.
Pricing
Salesforce Composable Storefront is included in the Salesforce Commerce Cloud B2C license.
3. SAP Composable Storefront (Spartacus)
SAP acquired Hybris, an on-premise and monolithic commerce platform, in 2013 and over the next decade worked to turn it into a cloud- and API-based solution, going through a few iterations of platform architecture and product naming to get there.
The release of SAP Commerce Cloud 2211, the first cloud-only version, in 2022 showed that SAP is now going all in on composable and headless commerce . This version introduced a much more modular architecture, followed by a new pricing model, that makes it easier for companies to combine core SAP commerce functionality with third-party solutions for other parts of the experience like content management or search.
SAP Composable Storefront is a frontend solution designed specifically for SAP Commerce Cloud. It’s a set of Angular libraries that developers can use to build JavasScript-based storefronts that connect to the backend through SAP’s Omni Commerce Connect (OCC) APIs. These libraries started as an open-source project, Spartacus , that was created as an alternative to the templated Accelerator storefronts. It is now an officially supported product, only available to SAP Commerce Cloud customers, and is the primary storefront solution offered by SAP (with the Accelerator templates now depreciated).
Key features
Angular single page application (SPA): Composable Storefront is a set of Angular libraries that contain frontend components and styling designed around Commerce Cloud features. Developers can create a JavaScript application and choose which versions of the libraries to use, then can configure and customize the storefront by overriding styling and code.
Ready-to-go B2B components: Many companies choose SAP Commerce Cloud for it’s ability to handle complex B2B use cases and the Composable Storefront library offers a lot of out-of-the-box storefront components built specifically for the advanced B2B features of the platform.
Integrated with the SAP ecosystem: Along with being developed to work seamlessly with Commerce Cloud functionality, Composable Storefront has many integrations with other SAP products with more on the roadmap.
SAP CC limitations
Only compatible with SAP Commerce Cloud implementations.
Frontend components are built specifically to work with the SAP ecosystem and data models, relying on APIs from both SAP Commerce Cloud and SAP SmartEdit (the CMS) to function out-of-the-box. So organizations that are looking to take full advantage of the new modular architecture of Commerce Cloud by integrating it’s functionality with other platforms, such as an alternative headless CMS , will likely need a more technology agnostic frontend solution.
Best for
Composable Storefront is a good choice when organizations are invested in SAP’s suite of business tools and want to be able to separate backend and frontend development, but don’t need integrations with many third party systems.
Pricing
SAP Composable Storefront is included in the SAP Commerce Cloud license.
4. commercetools frontend
commercetools is a natively headless platform that originally didn’t offer any frontend solution at all. It was one of the first major players in the headless space, and attracted a lot of early adopters of the architecture that were happy to build their own frontend.
In 2021 they acquired a FEaaS company, Frontastic, to be able to offer a storefront starter kit alongside their headless commerce platform. Now rebranded as commercetools Frontend, the solution offers a set of tools to build, deploy, and maintain React-based storefronts.
The underlying commerce engine, commercetools Composable Commerce, is still a very technology agnostic solution that can be used with any frontend framework. Frontend simply gives companies the option of a frontend starter kit with components that have been tailored to Composable Commerce functionality.
Key features
React PWA: Frontend provides developer tooling to build a storefront as a React app, providing a component library for common frontend elements as well as full starter storefronts, called “store launchpads”, for B2C retail and B2B manufacturing.
API hub: A backend-for-frontend that can be used to integrate the third-party services that power your customer experience.
Frontend Studio: A no-code page builder that lets business users drag-and-drop components and preview how pages will look on different devices.
commercetools limitations
Technically compatible with other commerce platforms, but only provides connectors for Composable Commerce and is only available to Composable Commerce customers.
Offers a limited amount of prebuilt components and integrations compared to the other storefront solutions on this list.
Best for
commercetools is a powerhouse when it comes to MACH architecture (microservices, APIs, Cloud, headless), and it’s likely that the typical large enterprise companies drawn to the very high flexibility of the platform are going to continue to build their own frontends.
With the growing popularity of composable commerce, however, there are now plenty of midsize companies that need a truly API-first commerce engine but don’t want to DIY their storefront. In this case, if you’re going with commercetools Composable Commerce as your backend engine then it’s worth checking out commercetools Frontend to see if it’s also the best fit for your stack.
Pricing
It’s currently not clear on the commercetools website if Frontend is sold as a standalone product or is packaged with Composable Commerce.
What's the difference between Alokai (Vue Storefront) enterprise and open-source?
Our open-source UI components library, Storefront UI , offers free and fully customizable frontend components built for Vue.js, React, and Qwik. It’s a great option for small and medium businesses that want to save time on website development.
For organizations that need enterprise-level support and scale, we offer a set of tools on top of Storefront UI to help teams quickly develop, connect, and deploy composable commerce frontends. Including:
Alokai Storefront : A customizable, production-ready application that covers the end-to-end ecommerce journey. Available as a React or Vue.js PWA.
Alokai Connect : A data orchestration layer that lets you unify data from all your backend systems into one API, with prebuilt integrations for market-leading ecommerce, CMS, search, and payment platforms.
Alokai Cloud : Infrastructure to host and deploy your storefront application, optimized for high performance and safety with a 99.9% uptime service level agreement (SLA).
Alokai Console : A monitoring tool that provides real-time insight into storefront performance.
Key features to consider before deciding on a frontend solution for your ecommerce platform
Headless architecture
For vendors, the big driver of making a backend platform headless is that it makes it more attractive to the growing number of businesses that don’t want to buy a big suite of tools from a single vendor but want to be able to mix-and-match their tech stack. So, the development of the headless commerce backend has a lot of focus on creating APIs that allow it to be easily integrated with third-party solutions, including a variety of frontend frameworks.
However, the frontend solution offered alongside these headless platforms is generally only for companies that use the vendor’s commerce engine. So while the storefront may be separated from the backend via APIs, the infrastructure and components are often designed around particular functionality and logic of the backend platform. Which can cause some limitations when it comes to customization and integrations with external systems.
Factors to look at:
The frontend only talks to the backend exclusively via APIs. This is the baseline definition of headless.
Updates to the frontend and backend can be deployed separately.
Frontend components aren’t dependent on a particular backend engine to work.
There’s a separate API orchestration layer between the frontend and backend application for integrations with third party systems.
Scalability
A scalable solution maintains performance as demand grows , like high website traffic or large product catalogs. Going headless, in general, allows you to scale a system more efficiently because it allows you to provision resources (like cloud instances) for the frontend separately.
How well the frontend performs as it scales will depend on a variety of factors including application architecture, deployment strategies, and the unique data models and integrations that a company implements.
Factors to look at:
How is the frontend implemented, such as a single page application (SPA) or a progressive web application (PWA)?
How does the application render pages for visitors, such as client side rendering (CSR) or server side rendering (SSR)?
How is the solution hosted and deployed? Including cloud options, caching strategies, and CDN coverage.
What tools are available to monitor your storefront’s performance?
Flexibility
A major reason that companies opt for a headless architecture is that they want to be able to customize and extend the customer experience based on their unique needs. Which means that while many teams want a prebuilt storefront to get up and running, they also need to be able to quickly adapt it to their business and easily change it as their needs evolve.
Factors to look at:
How customizable are the prebuilt storefront components?
Is it easy to add new functionality and integrations?
Are there prebuilt integrations with your existing tech stack?
Can you switch backend technologies in the future without disrupting the frontend customer experience?
Personalization
Personalization is going to be driven by the data in your backend tech stack, so the ability of the frontend solution to use that data is a key decision factor.
For companies that primarily use the personalization features of their commerce platform, having a storefront that is deeply integrated with those features out of the box can be the best option. While organizations that rely on personalization data from other systems are going to be more interested in the availability of prebuilt connectors , how easy it is to build custom integrations, and how the solution handles data orchestration .
Conclusion
Headless commerce is all about flexibility and, overall, the frontend solution you choose should enable you to launch storefronts quickly, fully leverage the data in your tech stack, and scale at the pace you need.
If you’d like to have a chat to see if Alokai is the right frontend for your headless transition, don’t hesitate to get in touch .