Remote configuration

Remote configuration lets you change application settings through a configuration release. With Featurevisor, you define typed values in Git, test them, publish a datafile, and let your application decide when to load updates.

Configuration parameters#

Use global variables for independent settings such as support addresses, payment methods, or service limits. Use feature variables when a value belongs to a feature rollout or experiment.

Start with the quick start to create a project. The following definitions can then be added to that project.

Variables#

Create a global variable without introducing a feature flag:

description: Payment methods available at checkout
type: array
items:
  type: string
defaultValue:
  - creditCard
  - paypal
overrides:
  production:
    - key: netherlands
      conditions:
        - attribute: country
          operator: equals
          value: nl
      value:
        - ideal
        - creditCard

Declare the attribute used by the override:

description: Country associated with the current user
type: string

The override applies to users whose context contains country: nl. Other users receive the default value. Global variables do not have their own percentage rollout.

Make sure your project has a Target that includes the variable. A Target with no selectors includes every active feature and global variable:

description: All application configuration

Evaluating variables using SDK#

Install @featurevisor/sdk in your application. After building and deploying the project's datafile, load it:

import { createFeaturevisor } from '@featurevisor/sdk'
const response = await fetch('https://cdn.example.com/production/featurevisor-all.json')
if (!response.ok) throw new Error('Could not load configuration')
const f = createFeaturevisor({ datafile: await response.json() })
f.getVariable('paymentMethods', { country: 'nl' })
// ['ideal', 'creditCard']
f.getVariable('paymentMethods', { country: 'gb' })
// ['creditCard', 'paypal']

Replace the example URL with your deployed datafile URL. Choose an application fallback for startup failures; see offline evaluation.

Overriding variables by rules#

Global variable overrides match conditions, reusable segments, or feature requirements. The first matching sibling wins. Nested overrides refine a matching parent's value, for example from country to city.

For structured objects, mutations let you author changes to selected properties. The builder resolves these into complete values in the datafile.

Defining our feature#

Choose a feature variable when the value should follow a rollout or variation. For example, a delivery estimate can belong to a checkout redesign. That application's call includes both keys:

const deliveryLabel = f.getVariable('checkout', 'deliveryLabel', {
  userId: 'user-123',
  country: 'nl',
})

This call assumes the checkout feature defines deliveryLabel in its variablesSchema. See feature variables for a complete definition.

Other ways of overriding variables#

A global variable can depend on a feature through requiredFeatures. The feature decides eligibility; the variable supplies the value. Its disabledValue or useDefaultWhenDisabled controls the result when requirements are unmet. See required features.

Use feature variables for values tied to percentage rollouts or experiment variations. Global variables with dependencies remain global variables, with their own names and overrides.

Testing configuration#

Test both the targeted value and the default:

variable: paymentMethods
assertions:
  - description: Netherlands uses the local payment method
    environment: production
    context:
      country: nl
    expectedValue:
      - ideal
      - creditCard
  - description: Other countries use the default
    environment: production
    context:
      country: gb
    expectedValue:
      - creditCard
      - paypal

Run npx featurevisor lint and npx featurevisor test before publishing. See testing before deployment for a CI workflow.

How do applications get latest configuration?#

Applications own fetching, polling, persistence, and error handling. The base SDK does not start a background refresh service.

After fetching a complete replacement datafile, call:

f.setDatafile(nextDatafile, true)

The second argument replaces the previous datafile, including removing definitions that are absent from the new one. Omit it when intentionally merging partial Target datafiles.

A Git change is not visible to users until the datafile has been published and their application has loaded it. Set CDN caching and refresh intervals accordingly.

Benefits#

Your configuration can be reviewed, validated, tested, and reverted using your existing Git workflow. The same datafile can serve browser, mobile, and backend applications through their respective SDKs.

Use the Cloudflare hosting example and Node.js consumer as runnable references. For deployment recovery, read configuration rollback.