feat(optimizely): implement optimizely provider

[JonCanning]

This PR

• adds a provider for Optimizely Feature Experimentation

[gemini-code-assist]

Summary of Changes

Hello @JonCanning, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces a new Optimizely provider for the OpenFeature Go SDK, enabling seamless integration with Optimizely Feature Experimentation. The provider allows Go applications to leverage Optimizely's feature flagging and A/B testing capabilities by mapping OpenFeature evaluation contexts to Optimizely user contexts, supporting various flag types and providing clear documentation and examples for implementation.

Highlights

• New Optimizely Provider: Introduces a new provider for Optimizely Feature Experimentation, integrating it with the OpenFeature Go SDK.
• Context Mapping: Explains how OpenFeature evaluation context is mapped to Optimizely user context, emphasizing the 'targetingKey' as the Optimizely user ID.
• Variable Key Selection: Details the mechanism for selecting variable values from Optimizely flags, allowing custom 'variableKey' attributes or defaulting to 'value'.
• Boolean Evaluation Logic: Clarifies that boolean flag evaluations return the 'Enabled' state of the Optimizely decision, not a specific variable value.
• Comprehensive Examples and Docs: Includes a README.md with installation and usage instructions, and an example.go demonstrating various flag type evaluations.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces a new Optimizely provider for the OpenFeature Go SDK. The implementation is a good start, but there are several areas for improvement. The core provider logic in provider.go contains significant code duplication that should be refactored for better maintainability. The accompanying tests in provider_test.go are minimal and need to be expanded to cover various evaluation scenarios and error conditions to ensure the provider's reliability. Additionally, the example code and README documentation could be clearer and more helpful for users trying to integrate the provider. My review includes specific suggestions to address these points.

[erka]

@JonCanning Thank you for raising this and for the work you’ve put in so far!

There are a few things we’ll need to address before moving forward:

• Please verify the DCO.
• Please follow the contributing guide for creating a new provider — a few additional steps are required to make this provider releasable.
• Is there a reason you aren’t using the latest versions of openfeature/go-sdk and Optimizely v2? Updating would be ideal.
• If the provider doesn't use StateHandler, there’s no need to implement Init and Shutdown.
• Please avoid using the pkg directory structure.
• Some modernization would be great (e.g., any instead of interface{}, using t.Context(), etc.). We are using go v1.24+ at the moment.
• Try to reduce duplication where possible. It may be feasible to return GenericResolutionDetail[T] directly from evaluate.
• For the README and example, please focus more on how to set up the provider itself rather than general usage of the OpenFeature Go SDK.

Thanks again, and happy to help clarify any of these!

[JonCanning]

Thanks for the feedback and apologies for the quality issues, I was a bit too "Jesus take the wheel" with AI. I have reworked it so it's all my fault now 🙂

[sahidvelji]

Thanks for this contribution! And, thank you @erka for the excellent feedback.

I noticed that there's an Optimizely Provider implementation in java-sdk-contrib, where the authors of that Provider have taken a different approach. For example, the Java Provider does not even support string, int, or float evaluations. I am not convinced that that's the right strategy though. Mapping vendor SDK concepts to OpenFeature concepts is not always straightforward. There are often multiple ways of doing so, each with their own trade-offs. Before accepting this contribution, I first really want to come to a consensus on the design of this Provider. I will try to get some more eyes on this.

https://github.com/open-feature/java-sdk-contrib/tree/main/providers/optimizely

[sahidvelji]

Sorry for the delay. This Provider is of particular interest to me because my org has built a custom internal Provider that wraps Optimizely. We spent quite a bit of time deliberating various design decisions. It's tough because Optimizely's flags are quite different from other vendors in the sense that a single flag key does not always map to a single value.

Here are my thoughts.

Optimizely consists of projects, where a project contains flags. Flag keys must be unique across a project, and flags in Optimizely can have zero or more variables. There are three main cases to consider when mapping these to OpenFeature: a flag with zero variables, a flag with one variable, and a flag with more than one variable. The OpenFeature evaluation methods only accept a flag key and return a single value. To solve for that, we considered several approaches:

1. Use dot-delimited structured access for flag keys. Something like flag_key.variable_key. This felt like a hack to us, and didn't seem to be aligned with how OpenFeature generally works. For example, this wouldn't work well with other OpenFeature tooling like the CLI.
2. Use the evaluation context to store the variable key, as is done in this PR. We decided against this approach also because if we ever migrate to a different feature flag platform, their Provider wouldn't have that functionality and client code would need to be modified. This sort of defeats the purpose of using OpenFeature, given that one of the benefits is a vendor-neutral SDK. Also, I'm not sure that this is the intended purpose of the evaluation context.
3. Wrap the OpenFeature SDK by implementing the same interface, but also including an extra method to handle evaluation of flags with multiple variables. For the same reason as above, this approach did not make sense to us since introducing a wrapper defeats the purpose of using OpenFeature.
4. Instead of wrapping the OpenFeature SDK, add a method to the Provider that handles evaluation of flags with multiple variables. Also not preferred since this isn't how OpenFeature is intended to be used.

Here's what we landed on:

For flags with no variables, we support only the bool evaluation method and the value of isFeatureFlagEnabled is returned.
All other evaluation methods return an error.

For flags with a single variable, we support the evaluation method based on the type and return the value of the only variable in the flag. If the type doesn't match, return an error.

For flags with multiple variables, we use the ObjectEvaluation method, which returns an object of variables names to their values. All other evaluation methods return an error.

There is a problematic case where a flag has a single variable and a developer attempts to add another variable. As an example, this would cause a string evaluation to suddenly error because it now has multiple variables. Since this case is not possible as long as the flag is "running" in production, we decided this is OK.

Let me know where I can clarify our approach.

[erka]

@sahidvelji Kinda sad that this hasn’t been open-sourced.

I think your approach is reasonable. We’ll probably need a good guide on how to use Optimizely with Open Feature ecosystem.

[sahidvelji]

Kinda sad that this hasn’t been open-sourced.

Since it's a custom Provider for an internal API, it wouldn't be of value to others. We were also hoping to build Optimizely SDK Providers (which we could open source), but that hasn't been prioritized.

[JonCanning]

Thanks @sahidvelji, that's very helpful, I'll update it with your suggestions

[sahidvelji]

The DCO check is failing. See https://github.com/open-feature/go-sdk/blob/main/CONTRIBUTING.md#developer-certificate-of-origin

[sahidvelji]

I will try to review this soon.