Feature/status resolution

[Stepami]

Why this PR?

Closes #604

Visible Changes

• IFeatureServiceProvider<TService> interface to get the implementation based on the feature status, maybe using additional context
• WithFeatureService<TService, TEnabled, TDisabled> extension method to setup feature service provider in di
• FeatureServiceProviderOptions class that specifies the keys used by a feature service provider to resolve an implementation based on the feature flag status when keyed di is available.

[Stepami]

Hello @zhiyuanliang-ms ! It's been a little while. Could you take a look at my proposal of the FeatureServiceProvider API please?

[zhiyuanliang-ms]

Hey, @Stepami Sorry for the late response. I actually discussed this with my colleague. We came up with the following design:

Introduce a new overload WithVariantService<TService, TEnabled, TDisabled>("FeatureFlagName")

The TEnabled and TDisabled are just used to specify the fallback implementation when there is no variant (in this case, the VariantServiceProvider will use feature flag status to retrieve service implementation from DI).

This is very similar to your proposal. But the benefit is that we don't need to introduce a new API with a new name and people can keep using IVaraintServiceProvider.

What do you think?

[Stepami]

Hey, @Stepami Sorry for the late response. I actually discussed this with my colleague. We came up with the following design:

Introduce a new overload WithVariantService<TService, TEnabled, TDisabled>("FeatureFlagName")

The TEnabled and TDisabled are just used to specify the fallback implementation when there is no variant (in this case, the VariantServiceProvider will use feature flag status to retrieve service implementation from DI).

This is very similar to your proposal. But the benefit is that we don't need to introduce a new API with a new name and people can keep using IVaraintServiceProvider.

What do you think?

@zhiyuanliang-ms

IVariantServiceProvider does not support context propagation for feature filters.

[jimmyca15]

@Stepami

Are you referring to the lack of a way to pass the filter context in as a parameter to resolve the service? That does seem like a deficiency of IVariantServiceProvider. We can consider how to address it.

[zhiyuanliang-ms]

Hey, @Stepami

IVariantServiceProvider does not support context propagation for feature filters.

This is a good call. We missed this for variant evaluation as well. ValueTask GetVariantAsync(string feature, ITargetingContext context, CancellationToken cancellationToken = default)

This makes thing tricky. It will be clean if we can add a new GetService method that takes a context parameter to IVariantServiceProvider. However, this will be a breaking change.

My current thought is that we can introduce a new IContextualVariantServiceProvider:

public interface IContextualVariantServiceProvider<TService> where TService : class
{
        ValueTask<TService> GetServiceAsync<TContext>(TContext context, CancellationToken cancellationToken);
}

We will have the current VariantServiceProvider to implement it as well. And the WithVariantService will then also register IContextualVariantServiceProvider to DI.

[Stepami]

@jimmyca15 yes i am! @zhiyuanliang-ms did a great job of explaining my point.

However, i still do not understand why status based resolution should be bound to variant evaluation

[zhiyuanliang-ms]

However, i still do not understand why status based resolution should be bound to variant evaluation

Hey, @Stepami
Variant feature flag is the super set of simple feature flag. For the design simplicity, we want to unify them into variant. If something supports variant, it should also support toggle feature flag too.