Hi everyone,
We are currently building a feature flag infrastructure for all our applications. We want to use AppConfiguration, AppConfiguration-DotnetProvider and FeatureManagement-Dotnet to store and check the feature flags on the applications. We'll build our own feature flag management app though, to provide advanced logic (custom filters, audit, authentication/authorization, more...) to our internal users.
Since we are in a micro-services environment, we would like to reuse a single Azure App Configuration to decrease the costs and, hopefully, the infrastructure complexity.
We would ideally like to use and watch feature flags the same way it's done with "classic" app configuration usage.
For example, with the SDK we can currently do this:
options.Select("App:MyApp:*");
options.Connect(new Uri(endpoint), credential).ConfigureRefresh(refreshOptions =>
{
refreshOptions.Register("App:MyAppSentinelKey", true);
});Bu this can't be done use feature flags.
The main reasons we would like to do this would be:
- to reduce the number of feature flags that are scanned every 30s (or whatever the cache expiration is set to)
Indeed, putting aside the overload that it surely represents on the AppConfiguration instance, it would also require multiple calls for each multiple of 100 feature flags, because of paging. Since our instance will be used by many apps, we expect it to contains many feature flags. If we imagine the app containing 1000 feature flags, this would mean that each app has to make 10 calls every 30s just to check if something has changed. We would break the 20k max requests per hour with just 17 apps.
Of course, this could mitigated by increasing the cache expiration, but we'd loose reactivity, with doesn't seems to be a good tradeoff.
- to avoid downloading feature flags updated data that aren't used by the application.
Indeed, with the currently implemented feature flag configuration, the app watches all the feature flags. This means that when a feature flag used by app A is updated, it will be watched & downloaded by app B, even if it doesn't use it.
For these reasons, we'd like to be able to use explicit .Select and .Register, which will eliminate those two drawbacks by providing the ability to select only the feature flags that are useful to the app, and by using sentinel keys that will be automatically updated by our Feature Flags management app.
We actually managed to enable this by copying and adapting this method
|
public AzureAppConfigurationOptions UseFeatureFlags(Action<FeatureFlagOptions> configure = null) |
into something like this:
public static class AzureAppConfigurationOptionsExtensions
{
internal static readonly TimeSpan DefaultFeatureFlagsCacheExpiration = TimeSpan.FromSeconds(30);
internal static readonly TimeSpan MinimumFeatureFlagsCacheExpiration = TimeSpan.FromMilliseconds(1000);
public static AzureAppConfigurationOptions UseMyFeatureFlags(this AzureAppConfigurationOptions options, Action<MyFeatureFlagsOptions> configure)
{
// This code is identical
var featureFlagOptions = new MyFeatureFlagsOptions();
configure?.Invoke(featureFlagOptions);
if (featureFlagOptions.CacheExpirationTime < MinimumFeatureFlagsCacheExpiration)
{
throw new ArgumentOutOfRangeException(nameof(featureFlagOptions.CacheExpirationTime), featureFlagOptions.CacheExpirationTime.TotalMilliseconds,
string.Format(ErrorMessages.CacheExpirationTimeTooShort, MinimumFeatureFlagsCacheExpiration.TotalMilliseconds));
}
// This is just a Reflection hack to add FeatureManagementKeyValueAdapter
var adapters = typeof(AzureAppConfigurationOptions).GetField("_adapters", BindingFlags.NonPublic | BindingFlags.Instance).GetValue(options) as IList;
var featureManagementKeyValueAdapter = Activator.CreateInstance(typeof(AzureAppConfigurationOptions).Assembly.GetType("Microsoft.Extensions.Configuration.AzureAppConfiguration.FeatureManagement.FeatureManagementKeyValueAdapter"), nonPublic: true);
adapters.Add(featureManagementKeyValueAdapter);
// This allows us to select only the flags that we use.
foreach (var featureFlagKey in featureFlagOptions.FeatureFlags)
{
options.Select(FeatureManagementConstants.FeatureFlagMarker + featureFlagKey, featureFlagOptions.Label);
}
options.ConfigureRefresh(r =>
{
r.SetCacheExpiration(featureFlagOptions.CacheExpirationTime);
// This allows us to use a sentinel key.
r.Register(FeatureManagementConstants.FeatureFlagScopeKey + featureFlagOptions.Scope, featureFlagOptions.Label, true);
});
return options;
}
}
internal class FeatureManagementConstants
{
public const string FeatureFlagScopeKey = ".appconfig.scope/";
public const string FeatureFlagMarker = ".appconfig.featureflag.my/";
public const string ContentType = "application/vnd.microsoft.appconfig.ff+json";
public const string SectionName = "FeatureManagement";
public const string EnabledFor = "EnabledFor";
}
public class MyFeatureFlagsOptions : FeatureFlagOptions
{
internal List<string> FeatureFlags { get; set; } = new List<string>();
public string Scope { get; set; } = default!;
// As you can see here, Feature Flags are opted-in
public void Use(string feature)
{
FeatureFlags.Add(feature);
}
}As you can see, this code isn't pretty, but quite simple.
Additionally to FeatureManagementKeyValueAdapter and _adapters which are respectively internal and private, there is one additional hack which consists of using a different prefix for the feature flags, that can be seen on FeatureManagementConstants.FeatureFlagMarker.
This is necessary because there is a check here that forces a full scanning during refresh if one of the watched key filter starts with .appconfig.featureflag/:
|
bool useDefaultQuery = !_options.KeyValueSelectors.Any(selector => !selector.KeyFilter.StartsWith(FeatureManagementConstants.FeatureFlagMarker)); |
By putting all of our feature flags under
.appconfig.featureflag.my/, we workaround this check.
So my final questions would be:
- Would it be possible to implement
AzureAppConfigurationOptions.Select and AzureAppConfigurationRefreshOptions.Register on feature flags usage? It could probably be additional properties/methods on FeatureFlagOptions, or perhaps another overload (or anything you could think of!).
- If not, could you please expose some
private/internal dependencies, so we can implement it ourselves? This would include exposing some way of adding FeatureManagementKeyValueAdapter, and also, ideally, provide a way to disable the global scan on AzureAppConfigurationProvider.LoadAll.
![dependabot[bot] avatar](https://avatars.githubusercontent.com/in/29110?v=4 "dependabot[bot]")
![microsoft-github-policy-service[bot] avatar](https://avatars.githubusercontent.com/in/95686?v=4 "microsoft-github-policy-service[bot]")
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent