Alokai

Alokai (formerly Vue Storefront) is an open-source framework for building fast, decoupled eCommerce frontends that work with any backend. Instead of shipping a single opinionated storefront, it splits the problem into a framework-agnostic core package of composable factories (useCartFactory, useProductFactory, useUserFactory, and more) and a lightweight Express-based middleware that proxies calls to whichever commerce platform a project actually runs on. The same generated composables work unchanged whether the backend is Magento, commercetools, Shopware, Shopify, Salesforce Commerce Cloud, or a custom API, because each platform just supplies plain async functions that the factories wrap in shared reactive state, loading/error handling, and SSR-safe caching.

On top of that core, the project ships framework adapters (nuxt-module, nuxt-theme-module, and newer Next.js/React tooling referenced in current docs), a CLI for scaffolding new projects and integrations, and companion packages like storyblok for CMS integration, redis-driver and http-cache for SSR response caching, and a separate Storefront UI component library for pre-built cart/PDP/PLP UI. The middleware’s registerIntegrations loader dynamically resolves per-platform API clients from a project’s own dependencies, keeping platform credentials and SDKs off the client and behind a generic /:integrationName/:functionName REST endpoint.

The project has rebranded from Vue Storefront to Alokai and now positions itself as a “Frontend as a Service” with a managed/cloud offering alongside the open packages; the vuestorefront/vue-storefront GitHub repository’s main branch has been stripped down to a README pointing to the current product, while the last full snapshot of the open-source monorepo (lerna-managed, MIT-licensed, Vue 2 based) lives on the repository’s legacy branch. That branch is the codebase this analysis is grounded in.

For teams that need to move off a monolithic PHP storefront, run multiple commerce backends behind one frontend, or build a custom UI on top of a platform like Shopify or Magento without being boxed in by that platform’s theme engine, Alokai’s factory/middleware pattern is the core value proposition — one frontend codebase, swappable backends.

What You Get

• A core package of factory functions (useCartFactory, useProductFactory, useUserFactory, useSearchFactory, and more) that generate backend-agnostic composables with shared loading/error state and SSR-safe caching.
• An Express-based middleware server (createServer.ts) exposing a generic /:integrationName/:functionName endpoint that proxies requests to platform API clients, keeping credentials off the client.
• Framework adapters — nuxt-module and nuxt-theme-module wire the composables into Nuxt’s lifecycle, with newer Next.js/React tooling referenced in current product docs.
• A CLI package (@vue-storefront/cli) with commands and infrastructure generators for scaffolding new projects and platform integrations.
• Companion packages for a storyblok CMS integration, redis-driver and http-cache for SSR response caching, plus a separate Storefront UI component library for pre-built cart/PDP/PLP UI.
• A full VuePress documentation site covering architecture, getting-started, migration, and integration guides.

Common Use Cases

• Replatforming a monolithic Magento or Shopware storefront to a fast, decoupled Vue/Nuxt or React/Next.js frontend without rewriting the backend.
• Running a single storefront frontend against multiple backends at once — e.g. commercetools for catalog and checkout plus Storyblok for content.
• Building a custom, fully-branded storefront on top of Shopify or another SaaS platform when the platform’s native theme engine is too limiting.
• Agencies standardizing on one frontend codebase and swapping the platform integration per client using the CLI scaffolding and theme starters.
• Building installable, offline-capable PWA storefronts using the SSR caching packages (http-cache, redis-driver) for performance.

Under The Hood

Architecture This is a modular Lerna/Yarn-workspaces monorepo with a clear, unidirectional dependency flow: platform-specific API clients are injected into core’s factory functions (useCartFactory, useProductFactory, etc.), which produce backend-agnostic Vue composables with shared reactive state (sharedRef), loading/error tracking, and SSR-aware caching; apiClientFactory wraps that call surface with a before/after hook pipeline and per-call custom-query overrides so integrators can alter request or response shape without touching core code; the middleware package then exposes those same API clients over a generic Express endpoint (/:integrationName/:functionName in createServer.ts), acting as a BFF that keeps platform credentials server-side. Because every platform integration and every generated composable conforms to the same Context/FactoryParams contract defined in core/src/factories, a breaking change to that contract would ripple through every downstream integration at once — a real coupling risk, though one that buys consistent behavior across a dozen-plus supported backends. Notably, the current product’s main branch on GitHub has had all code removed in favor of a README, with the last real snapshot of this architecture preserved on the legacy branch, suggesting active development has moved off this public repository.

Tech Stack The inspected (legacy) codebase is a TypeScript monorepo built with Lerna and Yarn workspaces. core targets Vue 2 (vue@^2.6.11) via @nuxtjs/composition-api; middleware is a plain Express 4 server layered with cors, helmet, and cookie-parser. Builds run through Rollup with rollup-plugin-typescript2, emitting both CommonJS and ES module bundles; tests run on Jest with ts-jest; documentation is a separate VuePress site; linting uses ESLint with vue-eslint-parser and @typescript-eslint; CI (.github/workflows/test.yml) runs lint, build, and test across a Node 14/16/18 matrix on every pull request. Optional redis-driver and http-cache packages add SSR response caching, and per-platform integrations are published as separate npm packages that plug into the middleware’s dynamic integration loader. Current product documentation references a parallel Next.js/React and SDK-based line (@vue-storefront/next, @vue-storefront/sdk) that isn’t present in this repository’s inspected branches, indicating the stack has expanded well beyond what’s version-controlled here.

Code Quality Every core package ships a co-located test suite using Jest, with extensive mocking of factory dependencies and explicit assertions on loading/error state transitions; the middleware package separates unit from integration tests using nock and supertest. TypeScript is used throughout, though the base tsconfig sets strict: false, so typing is present but not maximally enforced. Error handling is explicit rather than swallowed — the middleware’s request handler maps integration errors through a status-code helper and returns client-facing messages for 4xx while collapsing 5xx into a generic response. Naming follows a consistent useXFactory/useX convention, ESLint enforces style across JS/TS/Vue files, and CI gates every pull request on lint, build, and test across multiple Node versions.

What Makes It Unique The core idea is the “agnostic composable” pattern: core defines a composable’s reactive contract once (state refs, loading/error handling, SSR-safe shared state), and each backend just supplies plain async functions to a factory — the same composable then works unmodified across Magento, commercetools, Shopware, Shopify, or a custom API. Paired with the API client’s hook/extension pipeline and per-call custom-query overrides, this lets integrators reshape requests and responses without forking framework code, which is genuinely useful for agencies serving many commerce backends from one codebase. That said, the underlying technique — an adapter/factory pattern over a shared interface — is an established software pattern rather than a novel one, and comparable backend-swap capabilities exist in other composable-commerce tooling.

Self-Hosting

Licensing Model MIT licensed. The core, middleware, cli, nuxt-module, and storyblok packages on the repository’s legacy branch (the last full open-source snapshot) carry an MIT LICENSE.md with no license key requirement.

Self-Hosting Restrictions None found in the inspected source — no isPro, isEnterprise, or license-check logic exists anywhere in the core, middleware, or cli packages.

Enterprise Features Not documented in this repository. The vuestorefront GitHub organization’s public repo list shows at least one previously open integration (Checkout.com) was moved to a separate vuestorefront/enterprise repository that is no longer publicly accessible, suggesting some newer platform integrations may now be gated behind a commercial offering rather than shipped as open packages — but the specifics aren’t sourced from public docs.

Cloud vs Self-Hosted Alokai now markets itself primarily as a “Frontend as a Service,” implying a hosted/managed product exists alongside the self-hosted open packages, though the current README and this repository don’t document a concrete feature delta between the two.

License Key Required No — none of the inspected open packages contain license-key gating.