Update README to mention the usage of feature-based injection (variant service)

[zhiyuanliang-ms]

No description provided.

[jimmyca15]

Suggested change

	services.AddSingleton<IAlgorithm, AlgorithmBeta>();
	// Adds an implementation for `IAlgorithm`, which is consumed as a variant service above.
	services.AddSingleton<IAlgorithm, AlgorithmBeta>();

[jimmyca15]

What happens if we forget to register implementation for the service?

[zhiyuanliang-ms]

It will return null if there is no matched implementation found in the DI container.

[zhiyuanliang-ms]

How about adding an sentence to mention this after the section
"With the call above, ..."

Something like:

services.AddFeatureManagement() 
        .WithVariantService<IAlgorithm>("ForecastAlgorithm");

With the call above, IAlgorithm will be wired up with the variant feature flag ForecastAlgorithm. The GetServiceAsync method of IVariantService<IAlgorithm> will retrieve the variant service of IAlgorithm which matches the name of allocated variant of the ForecastAlgorithm flag, from the dependency injection container. If there is no appropriate variant service found, the GetServiceAsync method will return null.

[jimmyca15]

How about

The call above makes IVariantServiceProvider<IAlgorithm> available in the service collection. Implementation(s) of IAlgorithm must be added separately via an add method such as services.AddSingleton<IAlgorithm, SomeImplementation>(). The implementation of IAlgorithm that the IVariantServiceProvider uses depends on the ForecastAlgorithm feature. If no implementation of IAlgorithm is added to the service collection, then the IVariantServiceProvider<IAlgorithm>.GetServiceAsync() will return a task with a null result.

[rossgrambo]

Maybe we should add a "why?" here, because there's only a narrow reason they would want to use the overrides. It's if a customer wants to allocate via variants without changing their existing IsEnabled code. Meaning they want to return bool results but have more than 2 "buckets".

[zhiyuanliang-ms]

Today, feature filters can be used to conditionally enable feature flags. Variants should be able to extend this functionality by also playing a role in the decision to enable a feature flag. A property can be included in a feature flag’s variants giving them the opportunity to override the flag’s enabled state. This is important considering the enabled state of a flag is used in our integration points with ASP.NET Core such as the FeatureGateAttribute

quoted from the design doc

This is the original purpose for this design.

This gives variants an opportunity to extend the evaluation of a feature flag.

I think this sentence is a solid reason but we may come up a good story or an attracting use case of statusOverride.

[rossgrambo]

This is important considering the enabled state of a flag is used in our integration points with ASP.NET Core such as the FeatureGateAttribute

This part is valid, but it's still not a big use case. Essentially, customers can always use a normal flag with filters to achieve whatever boolean targeting they want to achieve. Variants don't offer an advantage to boolean targeting over the standard TargetingFilter.

One reason someone would use Variants in the bool world is to adding more telemetry "buckets" so they can split their traffic (although this is also not necessary as the split traffic of "true" results should be equal).

Another reason is if a customer's plan is to call both GetVariant and IsEnabled(like using FeatureGateAttribute) on a single flag, then they might use it, but this is likely overloading what a flag should be in charge of.

My fear is that users will see this section in the readme and think that they should be using it- instead of using it to address a specific problem.