Configuration
go-feature-flag needs to be initialized to be used.
During the initialization you must give a ffclient.Config{} configuration object.
ffclient.Config{} is the only location where you can put the configuration.
Configuration fields
| Field | Description |
|---|---|
Retriever | The configuration retriever you want to use to get your flag file See Store your flag file for the configuration details. This field is optional if Retrievers is configured. |
Retrievers | Retrievers is exactly the same thing as Retriever but you can configure more than 1 source for your flags.All flags are retrieved in parallel, but we are applying them in the order you provided them (it means that a flag can be overridden by another flag). See Store your flag file for the configuration details. This field is optional if Retrievers is configured. |
Context | (optional) The context used by the retriever. Default: context.Background() |
Environment | (optional) The environment the app is running under, can be checked in feature flag rules. Default: ""Check "environments" section to understand how to use this parameter. |
DataExporter | (optional) DataExporter defines the method for exporting data on the usage of your flags. see export data section for more details. |
FileFormat | (optional) Format of your configuration file. Available formats are yaml, toml and json, if you omit the field it will try to unmarshal the file as a yaml file.Default: YAML |
LeveledLogger | (optional) LeveledLogger is used to log what go-feature-flag is doing.It should be a slog instance.If no logger is provided the module will not log anything. Default: No log |
Notifiers | (optional) List of notifiers to call when your flag file has been changed. See notifiers section for more details. |
PollingInterval | (optional) Duration to wait before refreshing the flags. The minimum polling interval is 1 second. Default: 60 * time.Second |
EnablePollingJitter | (optional) Set to true if you want to avoid having true periodicity when retrieving your flags. It is useful to avoid having spike on your flag configuration storage in case your application is starting multiple instance at the same time. We ensure a deviation that is maximum ±10% of your polling interval. Default: false |
StartWithRetrieverError | (optional) If true, the SDK will start even if we did not get any flags from the retriever. It will serve only default values until the retriever returns the flags. The init method will not return any error if the flag file is unreachable. Default: false |
Offline | (optional) If true, the SDK will not try to retrieve the flag file and will not export any data. No notifications will be sent either. Default: false |
EvaluationContextEnrichment | (optional) It is a free All those fields will be included in the custom attributes of the evaluation context. If in the evaluation context you have a field with the same name, it will be overridden by the If you have a key |
PersistentFlagConfigurationFile | (optional) If set GO Feature Flag will store the flags configuration in this file to be able to serve the flags even if none of the retrievers is available during starting time. By default, the flag configuration is not persisted and stays on the retriever system. By setting a file here, you ensure that GO Feature Flag will always start with a configuration but which can be out-dated. (example: /tmp/goff_persist_conf.yaml) |
Example
ffclient.Init(ffclient.Config{
PollingInterval: 3 * time.Second,
LeveledLogger: slog.Default(),
Context: context.Background(),
Environment: os.Getenv("MYAPP_ENV"),
Retriever: &fileretriever.Retriever{Path: "testdata/flag-config.goff.yaml"},
FileFormat: "yaml",
Notifiers: []notifier.Notifier{
&webhooknotifier.Notifier{
EndpointURL: " https://example.com/hook",
Secret: "Secret",
Meta: map[string]string{
"app.name": "my app",
},
},
},
DataExporter: ffclient.DataExporter{
FlushInterval: 10 * time.Second,
MaxEventInMemory: 1000,
Exporter: &file.Exporter{
OutputDir: "/output-data/",
},
},
StartWithRetrieverError: false,
})
Multiple configuration flag files
go-feature-flag comes ready to use out of the box by calling the Init function and, it will be available everywhere.
Since most applications will want to use a single central flag configuration, the package provides this. It is similar to a singleton.
In all the examples above, they demonstrate using go-feature-flag in its singleton style approach.
Working with multiple go-feature-flag
You can also create many go-feature-flag clients to use in your application.
Each will have its own unique set of configurations and flags. Each can read from a different config file and from different places.
All the functions that go-feature-flag package supports are mirrored as methods on a GoFeatureFlag.
Example
x, err := ffclient.New(Config{ Retriever: &httpretriever.Retriever{{URL: "http://example.com/flag-config.goff.yaml",}})
defer x.Close()
y, err := ffclient.New(Config{ Retriever: &httpretriever.Retriever{{URL: "http://example.com/test2.goff.yaml",}})
defer y.Close()
user := ffcontext.NewEvaluationContext("user-key")
x.BoolVariation("test-flag", user, false)
y.BoolVariation("test-flag", user, false)
// ...
When working with multiple GoFeatureFlag, it is up to the user to keep track of different GoFeatureFlag instances.
Offline mode
In some situations, you might want to stop making remote calls and fall back to default values for your feature flags.
For example, if your software is both cloud-hosted and distributed to customers to run on-premise, it might make sense
to fall back to defaults when running on-premise.
You can do this by setting Offline mode in the client's Config.