Remote config and feature flags

Define parameters (a flag, a text, a number or JSON) with a default value and, optionally, values for conditions. Your edits are a draft; publish makes them a new immutable version that apps fetch. Every version is kept (up to your plan), so a bad change is one rollback away. Apps get only their own evaluated values: targeting rules, which can name users, never leave the server.

sov.config.setDefaults({ new_checkout: false, banner: 'Welcome' })
sov.config.settings({ storage: indexedDbStorage(), appVersion: '2.4.1', attributes: { plan: 'pro' } })
await sov.config.fetchAndActivate()          // at most every 12 hours unless a publish signal arrives

if (sov.config.getBool('new_checkout')) showNewCheckout()
const off = sov.config.onUpdate((keys) => rerender(keys))   // live, within a second of a publish

#Conditions

A condition is a rule tree. Combine rules with all, any and not. The first matching condition (lowest priority number) gives a parameter its value; with no match, the default applies.

#Publishing safely

1. 1

   Review the change

   Review and publish shows what changes against the live version and who changes: how many recently seen users would get a different value.

2. 2

   Publish (or schedule)

   A publish is refused if someone else published since you looked. On paid plans you can pick a time instead.

3. 3

   Apps update

   Apps listening with onUpdate refetch within a second (the signal carries only the version number). Others pick it up at their next fetch; an unchanged config costs a 304.

4. 4

   Roll back

   Versions › Roll back publishes an older version again as a new one.

#Keep config in git

sov config pull                      # writes sovaria/config.json (commit it)
sov config push                      # replace the draft from the file (nothing goes live)
sov config diff                      # in the pull request
sov config publish -m "Turn on new checkout" --yes   # on merge
sov config rollback 41 --yes

#Plans and limits