feat: add standardized environment variable configuration pattern for OFREP SDKs

[askpt]

Signed-off-by: André Silva 2493377+askpt@users.noreply.github.com

This PR

This pull request adds a new Architecture Decision Record (ADR) describing a standardized pattern for configuring OFREP SDKs using environment variables. The ADR proposes aligning with industry best practices from OpenTelemetry, aiming to improve consistency, flexibility, and cloud-native compatibility for SDK configuration.

Related Issues

Fixes #53

[slashmo]

Suggested change

	- **OFREP_ENDPOINT**: The base URL for the OFREP service (e.g., `http://localhost:2321`)
	- **OFREP_HEADERS**: Additional HTTP headers in comma-separated key=value format (e.g., "Authorization=Bearer 123,Content-Type=application/json")
	- **OFREP_TIMEOUT**: Request timeout in milliseconds (e.g., "5000")
	- **OPEN_FEATURE_PROVIDER_OFREP_ENDPOINT**: The base URL for the OFREP service (e.g., `http://localhost:2321`)
	- **OPEN_FEATURE_PROVIDER_OFREP_HEADERS**: Additional HTTP headers in comma-separated key=value format (e.g., "Authorization=Bearer 123,Content-Type=application/json")
	- **OPEN_FEATURE_PROVIDER_OFREP_TIMEOUT**: Request timeout in milliseconds (e.g., "5000")

Quoting myself from #53 (comment):

I like how the OTel spec groups everything into OTel at the first level and then nests the OTLP specific configuration inside. Have you considered this approach for OFREP as well so we leave room for a common root key that's used by OFREP but also any other potential top-level OpenFeature configuration?
Following the example of OTEL_EXPORTER_OTLP_ENDPOINT, we could have OPEN_FEATURE_PROVIDER_OFREP_ENDPOINT, OPENFEATURE_PROVIDER_OFREP_ENDPOINT, OF_PROVIDER_OFREP_ENDPOINT, OPEN_FEATURE_OFREP_ENDPOINT, OPENFEATURE_OFREP_ENDPOINT or OF_OFREP_ENDPOINT?

[askpt]

I also prefer your idea. Leaving this open for further discussion.

[beeme1mr]

I don't have a strong preference either way but OPEN_FEATURE_PROVIDER_OFREP_ENDPOINT feels overly verbose.

[askpt]

@beeme1mr What are your thoughts on OPEN_FEATURE_OFREP_ENDPOINT only?

[beeme1mr]

I'm assuming this is geared towards server use cases. Should we add any considerations for web or mobile?

[beeme1mr]

I don't have a strong preference either way but OPEN_FEATURE_PROVIDER_OFREP_ENDPOINT feels overly verbose.

[askpt]

I'm assuming this is geared towards server use cases. Should we add any considerations for web or mobile?

At this point it is only considering server use cases. I don’t know if it should be part of this ADR or a separate one for the client/web uses.

[weyert]

I was thinking maybe we can do OF_OFREP_ENDPOINT? Besides of that it all makes sense

[askpt]

I was thinking maybe we can do OF_OFREP_ENDPOINT? Besides of that it all makes sense

I don't have any particular issues with naming. I think we just need to reach a consensus on which version we will take. At the moment we have:

1. OPEN_FEATURE_PROVIDER_OFREP_* -> 👍
2. OFREP_* -> 🚀
3. OF_OFREP_* -> ❤️
4. OPEN_FEATURE_OFREP_* -> 😄

Please vote with a reaction to have an idea on what is on peoples' head.

I think the ENDPOINT, TIMEOUT and HEADERS we have an agreement.

[lukas-reining]

Thanks for kicking this off @askpt!
I think it is good to consider being able to have other OF specific environment variables.

OFREP_*

To me it makes sense to have all OpenFeature related vars under a common prefix.
This makes it easier to oversee any OF related config.

OPEN_FEATURE_*

I think I would prefer OF_ for conciseness.

OPEN_FEATURE_PROVIDER_OFREP_*

The question to me here is, if provider really want to prefix their env variables with OPEN_FEATURE_ at all.
To me something like OFREP is special as it is part of the project.

On the other hand, having _PROVIDER_ would contribute to the before mentioned argument that a common prefix makes it easy to understand all OF related config. On the other hand, some providers are already consuming env vars through their base SDK, which makes the config transparent to the provider anyways.

To sum up, I am leaning towards OF_OFREP_* for this. I can also see OF_PROVIDER_OFREP_* if we want other providers to use the prefix as discussed above.

[askpt]

Thanks for kicking this off @askpt! I think it is good to consider being able to have other OF specific environment variables.

OFREP_*

To me it makes sense to have all OpenFeature related vars under a common prefix. This makes it easier to oversee any OF related config.

OPEN_FEATURE_*

I think I would prefer OF_ for conciseness.

OPEN_FEATURE_PROVIDER_OFREP_*

The question to me here is, if provider really want to prefix their env variables with OPEN_FEATURE_ at all. To me something like OFREP is special as it is part of the project.

On the other hand, having _PROVIDER_ would contribute to the before mentioned argument that a common prefix makes it easy to understand all OF related config. On the other hand, some providers are already consuming env vars through their base SDK, which makes the config transparent to the provider anyways.

To sum up, I am leaning towards OF_OFREP_* for this. I can also see OF_PROVIDER_OFREP_* if we want other providers to use the prefix as discussed above.

Thanks for your contribution @lukas-reining.
I prefer the OPEN_FEATURE_* because it makes it more explicit that it is an Open Feature variable. By using OF we are hiding that information a little bit. We both know it relates to Open Feature, but new people joining a new project might not.

[erka]

Thanks for your contribution @lukas-reining. I prefer the OPEN_FEATURE_* because it makes it more explicit that it is an Open Feature variable. By using OF we are hiding that information a little bit. We both know it relates to Open Feature, but new people joining a new project might not.

I like it. OPEN_FEATURE_ENDPOINT, OPEN_FEATURE_TIMEOUT and OPEN_FEATURE_HEADERS right? 😄

[lukas-reining]

Okay fine to me @askpt. I think it is okay to use OF, OTEL started to do it too at some point. But OPEN_FEATURE is okay. Do you have an opinion regarding the _PROVIDER_?

[askpt]

Thanks for your contribution @lukas-reining. I prefer the OPEN_FEATURE_* because it makes it more explicit that it is an Open Feature variable. By using OF we are hiding that information a little bit. We both know it relates to Open Feature, but new people joining a new project might not.

I like it. OPEN_FEATURE_ENDPOINT, OPEN_FEATURE_TIMEOUT and OPEN_FEATURE_HEADERS right? 😄

@erka I believe we need to have _OFREP_. These variables are specific to OFREP, and we should aggregate that way.

Okay fine to me @askpt. I think it is okay to use OF, OTEL started to do it too at some point. But OPEN_FEATURE is okay. Do you have an opinion regarding the _PROVIDER_?

@lukas-reining I would prefer OPEN_FEATURE_OFREP_ENDPOINT or possibly if the providers want to implement OPEN_FEATURE_FLAGD_ENDPOINT.

My general idea would be OPEN_FEATURE_{provider}_{variable}. This ADR only tackles OFREP, but I can see, as you mentioned, expanded to other providers that might want to adopt this naming.

[erka]

@erka I believe we need to have _OFREP_. These variables are specific to OFREP, and we should aggregate that way.

It’s actually my point. We don’t need the provider name there. Using _OFREP_, _FLAGD_, or _NAME_IT_ is basically just vendoring the env vars. And realistically, 99.9% of people use only one provider in their project or service. Just think about it...

[askpt]

@erka I believe we need to have _OFREP_. These variables are specific to OFREP, and we should aggregate that way.

It’s actually my point. We don’t need the provider name there. Using _OFREP_, _FLAGD_, or _NAME_IT_ is basically just vendoring the env vars. And realistically, 99.9% of people use only one provider in their project or service. Just think about it...

I am thinking on the 0.1%. Imagine those that are using multi-provider or similar. (Please note for multi-provider, multiple ofrep environment variables won't work)

[erka]

Please note for multi-provider, multiple ofrep environment variables won't work

There is another won't work case for vendored env names.

In fact, due to the recent extended outage caused by AWS that also hit LaunchDarkly, I have setup a LaunchDarkly Relay Proxy and with the use of Multi-Provider it points to upstream and the relay.

Originally posted in open-feature/go-sdk-contrib#758 (comment)