Support default values
beeme1mr opened this issue · 6 comments
Many feature flag SDKs accept an optional argument that represents the default value of the flag. This value is typically used when there is an issue fetching the ruleset or the feature flag ID is invalid.
Questions we should answer:
- Should the default argument be optional?
- How will the developer know why a default argument is being used?
Should the default argument be optional?
Some (I don't know how many) providers require an optional value in their API.
I don't see a lot of benefit in making the default argument optional. It's dead easy (either in the API layer or in the provider layer) to set the default value to a be (emptystring|false|0) if a given provider requires a default value
How will the developer know why a default argument is being used?
Why should the developer need to know if a default argument is being used? It's an internal concern of the flag evaluation logic. To me, it makes sense to keep this encapsulated within the provider's logic and not expose it to the caller of the SDK. I can't see a use-case for it.
Why should the developer need to know if a default argument is being used?
If I'm understanding correctly, I think @beeme1mr 's concern is that when a default is used, it may be due to a communication failure, or because the flag hasn't been defined in the infrastructure/control-plane. I could understand that as a DevOps engineer, that might be something important to know about. I'm unsure if it needs to be part of the spec, or it's something we leave up to providers.
There might be some overlap here with #7
Looking through #7, I think it makes sense that if the flag evaluation reasoning is to be provided to the developer, then it should be done as a separate concern (either via a separate API or via an additional reason object returned with the call).
At this point, I think it makes sense to keep the API for evaluating flags 'clean' and not try to put too much in there, as 99% of the time, the developer will only care about the returned flag value.
Encapsulating all evaluation reasoning information in a separate object/call makes it easier to modify later as the use-cases get fully-established.
I agree that most of the time the developer doesn't care about the reason why a flagging decision returned a certain outcome. At the point where the flagging decision is being requested, there's really not much that developer could do to handle an exceptional case, besides log the issue and pick a default value anyway.
Seems that we could provide a lower-level method/function that a developer could use when they DO need a richer, more detailed evaluation result, plus a higher-level API that wraps that to handle the happy path - "just tell me whether flag X on or off".
I think when discussing the "does the developer need to understand the logic?" question, we should take as an assumption that the SDK itself is instrumented with otel so we still get visibility into failures to call the upstream system. Emitting telemetry is the main use-case we have for wanting that info.
We decided to make default values required. The reason property can be used to determine why a default was set.