go-feature-flag v1, new flag format

[thomaspoignant]

Hello,

go-feature-flag is super easy when it comes to writing your flags in a config file, but it has a limitation, you cannot have multiple variations in your flags.

That's the reason why I wanted to introduce a new way to write your flags, it will be more verbose to write them, BUT it will give you a fine-grained possibility to set up your configuration.

Let's say we have something like this before:

test-flag:
  rule: key eq "random-key"
  percentage: 100
  true: true
  false: false
  default: false

We could translate that like this:

test-flag:
  variations:
    VariationDefault: false  # the name could be anything
    VariationBar: false
    VariationFoo: true
  targeting:
      rule-number-1: # a name for the rule, you can have as many rule you want
          query: key eq "random-key"
          percentage:
              VariationBar: 0
              VariationFoo: 100
  default:
      variation: VariationDefault

It allows way more possibility.

To have an easy migration path, we can also keep supporting the old format for sometimes.

Do you think it could improve the way go-feature-flag is working?

[urso]

Do you have a document with more examples?

How will the rule given be evaluated? I see that targeting can have multiple rules yet defaultRule.variation references VariationDefault? Is defaultRule the value to choosen if no rule in targeting matches? If I have multiple rules under targeting, can I control which one to run?

Just thinking out loud, but maybe you have considered all of that already:

Although the new format seems to be much more flexible I also find it quite difficult to understand. Plus, people with less experience about feature flags would have a hard time to do changes.

Given your new YAML format I wonder if one could 'type' the kind of format rule like so:

<flag-name>
  <rule-kind>:
    <rule-settings>

variations rules seem to follow this format already.

Some simple use-cases (especially projects just starting with feature-flags) a 'simple' set of rule kinds would be nice to have.

Plus you can add rule kinds more easily in the future without breaking existing setups.

Having a <rule-kind> one could introduce other more simple formats that less technical people can easily understand. E.g.

dev-flag:
  always-true:

vs.

dev-flag:
  always-false:

Alternatively to always-true and always-false I can think of a single bool flag like so:

dev-flag:
  bool:
    value: true

Or a simple value-flag for simple cases like so:

dev-flag:
  value: true  # can be an integer as well

For very simple A/B testing:

new-feature:
  a/b-test:   # boolean flag that returns true for 60% of our users
    percentage: 60

Using this configuration style one could migrate legacy rules into this format (which is not too difficult to automate):

test-flag:
  legacy:  #  well... maybe you have a more descriptive name :)
    rule: key eq "random-key"
    percentage: 100
    true: true
    false: false
    default: false

[thomaspoignant]

@urso I love the ideas, definitely, the new format will be harder to maintain.
Adding a layer to simplify even more the configuration could help a lot to have a different level of displaying the information.

Concerning the last element, I want to have backward compatibility and avoid breaking the actual configuration files.

I am off for a few days, but I will try to answer your questions about the format in detail when I am back.

[urso]

Concerning the last element, I want to have backward compatibility and avoid breaking the actual configuration files.

Fair. Another alternative solution I can think of is to version the flags configuration file. For example:

version: 0

test-flag:
  rule: key eq "random-key"
  percentage: 100
  true: true
  false: false
  default: false

for legacy configuration.

And for the 1.0 format:

version: 1

...

If version is missing we choose a default one (e.g. 0 in order to support legacy configs out of the box). But even requiring users to add a version: 0 to their existing config files is a very minimal change. It is great that you try to support existing configuration, but on the other hand the lib is not v1 yet and some breaking changes are to expected.

Having version, support for "legacy" rule kinds as in my former example, and support for reading configurations from multiple files (each with a potentially different format) already gives my quite a many options to slowly migrate existing configurations to the new format while starting to introduce the new format in new projects (or new feature flags).

About "multi-file-support": I do not expect go-feature-flag to provide me that feature. I consider this lib and other SDKs like LaunchDarkly as the 'low-level' services in my code base. The SDKs/libs are 'abstracted' like this:

// Provider interface gives access to feature flags evaluation.
type Provider interface {
	// Close the provider and cleanup resources.
	Close()

	// HasFeatureFlag checks if the feature flag name is known to the provider.
	HasFeatureFlag(name string) bool

	// GetBool queries the provider for a feature flag bool value.
	GetBool(name string, defaultValue bool, key string, attributes map[string]interface{}) bool

	// GetInt queries the provider for a feature flag int value.
	GetInt(name string, defaultValue int, key string, attributes map[string]interface{}) int

	// GetString queries the provider for a feature flag string value.
	GetString(name string, defaultValue string, key string, attributes map[string]interface{}) string
}

Fortunately this interface is very compatible with almost all SDKs/libs. The interface already allows me to combine multiple instances of go-feature-flag within my application (mix of multiple files and read from github), or have a simple in-memory implementation for testing.

[thomaspoignant]

@urso I finally have the time to answer you properly.

How will the rule given be evaluated? I see that targeting can have multiple rules yet defaultRule.variation references VariationDefault? Is defaultRule the value to choosen if no rule in targeting matches? If I have multiple rules under targeting, can I control which one to run?

Yes you can have multiple rule in targeting and we will evaluate the rule in order, as soon as the rule apply we will evaluate it and return the flag value.
If no rules in targeting apply, we will use the defaultRule.

Although the new format seems to be much more flexible I also find it quite difficult to understand. Plus, people with less experience about feature flags would have a hard time to do changes.

Yes, this is also what I am worried about, it adds more control over your flag but it is also more complex.
I am still wondering what is the ideal situation here. But your proposal on having simple format (always-false, a/b-test, etc ...) is a good one. We can probably have both format, a simple one and a advanced one,

[thomaspoignant]

I have reviewed the flag format a bit the format and it should be an array for the targeting to be sure we handle them in order.

test-flag:
  variations:
    VariationDefault: false  # the name could be anything
    VariationBar: false
    VariationFoo: true
  targeting:
      - name: rule-number-1
        query: key eq "random-key"
        percentage:
            VariationBar: 0
            VariationFoo: 100
      - name: rule-number-2
        query: key eq "random-key"
        percentage:
            VariationBar: 0
            VariationFoo: 100

  default:
      variation: VariationDefault

[thomaspoignant]

The roadmap for the version 1.0.0 is available in this issue #291