Config Switcher

The config switcher lets one middleware deployment serve many storefronts - brands, regions, or A/B variants - by swapping (parts of) an integration's configuration per request.

import { createConfigSwitcherExtension } from "@alokai/connect/config-switcher";

Add the extension

createConfigSwitcherExtension returns a regular middleware extension. Attach it to an integration and provide the configuration variants; each variant is a deep partial merged over the integration's base configuration.

import { createConfigSwitcherExtension } from "@alokai/connect/config-switcher";

const configSwitcher = createConfigSwitcherExtension({
  configuration: {
    "brand-a": { api: { baseSiteId: "brand-a" } },
    "brand-b": { api: { baseSiteId: "brand-b" } },
  },
});

export const config = {
  integrations: {
    commerce: {
      location: "@vsf-enterprise/sapcc-api/server",
      configuration: baseConfiguration,
      extensions: (extensions) => [...extensions, configSwitcher],
    },
  },
};

The configuration map can also be an async function - fetch variants from an API or database and let the built-in cache (cacheTTL) keep request latency flat.

Options

Switch strategies

Which variant a request gets is decided by the switchStrategy:

• header (default) - reads the x-alokai-middleware-config-id request header; defaultHeaderValue applies when it is absent.
• domain - resolves the variant from the request's domain, so brand-a.example.com and brand-b.example.com map to their own entries.
• Custom - pass an object with resolveConfigId(req) to derive the variant from anything on the request (path, cookie, tenant token, ...).

const configSwitcher = createConfigSwitcherExtension({
  configuration: loadVariants,
  switchStrategy: {
    resolveConfigId: (req) => req.headers["x-tenant-id"] ?? "default",
  },
});

On the SDK side, getConfigSwitcherHeader in the request config sets the matching header for every outgoing call.