[Feature Request] Dynamic Config

[saurabhnemade]

Not sure if anyone thought of adding it to Unleash but putting out an idea and proposal for discussion on Dynamic Config.

Purpose:

• To store frequently changing some global config and having non disrupted prod environments
• To quickly react to fragile config in prod environments
• It can have multi-environment config for dev/prod and enable different config with ability to keep backward compatibility support while doing upgrades or feature extensions.

Why its different from feature flag?

Sometimes we don't need yes/no or if yes give this segment. Sometimes in development you just need a configurable, maintainable json configuration.
Its just a json config which gets validated against optional schema that user may or may not provide. If user provides a schema then it uses that schema to validate the given config before updating it (on api level).

Use cases:

• Dynamic configuration of UI feature json
• Dynamic configuration of Backend feature
• Dynamic configuration to quickly support fallback urls
• Dynamic configuration to quickly support fallback credentials
• Dynamic configuration to quickly support fallback llm providers

A few examples:

name = uI_global_rollout_config
schema = null
value = {
     showTitle: true,
     brandName: "My whitelisted brand",
     url: "http://target.nonexistenet.com"
}

name = scraping_urls_proxies
schema = {
  "type": "object",
  "properties": {
    "proxyFallback": {
      "type": "array",
      "items": {
        "type": "string",
        "pattern": "^[^:@\\s]+:[^:@\\s]+@[^:@\\s]+:\\d+$"
      },
      "minItems": 1
    }
  },
  "required": ["proxyFallback"],
  "additionalProperties": false
}
value = {
    proxyFallback: [
        "user1:[email protected]:3011",
        "user1:[email protected]:3011"
    ]
}

Performance:

For optimal performance, the config can be super easily cached and served to million of calls without much additional efforts. No need to worry about stickiness of config. Its always constant and updates only when globally updated. Clients can cache it and reuse it until they make another call and find out it has been changed.

If you want, you can extend and monitor traffic count on the global config just for providing nice dashboards or identifying incidents or anything else.

[ivarconr]

Hi, thanks for sharing. This makes perfect sense to me. Unleash already have the variant json payload, which is almost what you talk about, with some minor excpetions:

1. No schema support (poc here)
2. No override/version support, meaning you currently need to copy the json blob around, which is not ergonomic.

This is on our backlog, but we are not able to commit any timeline just yet.