Create a feature flag service

[austinlparker]

Objective

To allow for dynamic modification of service behavior through feature flags, and to demonstrate OpenTelemetry in another language, create a feature flag service in Erlang+Elixir/Phoenix.

• UI/API to perform CRUD operations on flags.
• UI to display flag state.
• API to query flag state.
• Flags should be persistent through restarts (stateful storage).

Other services in the application should be able to register with this service and query it for the state of any feature flags defined in their code.

If feasible, it would be good to see if we can align with OpenFeature for definitions/semantic conventions here.

[tsloughter]

OpenFeature looks pretty early and focusing on hooks and evaluation at this point. I'd be fine modeling the feature flag data model off of them but I don't see a clear spec for that. I don't think we should, at least at this point, do any more than the most basic of, "is this flag true or false".

Happy to base the data structure on openfeature so it could in the future, if deemed useful, do more advanced forms of feature evaluation, if it is there in the spec and I'm just missing it :).

[beeme1mr]

Hey @austinlparker and @tsloughter, I'm working on OpenFeature and would love to help out where we can. Our project is still in an early stage but I think it would make sense to align where possible.

I would recommend you continue building out everything you described above but consider using the OpenFeature SDK and a custom provider that interacts with your service. That would fit nicely into our provider pattern we've defined in the spec. Ping me if you have any questions.

[austinlparker]

Is there an OpenFeature SDK for Erlang?

[austinlparker]

... and, I guess, every other language that would need to evaluate flags. 🙃

[austinlparker]

OpenFeature looks pretty early and focusing on hooks and evaluation at this point. I'd be fine modeling the feature flag data model off of them but I don't see a clear spec for that. I don't think we should, at least at this point, do any more than the most basic of, "is this flag true or false".

Yeah, this is mostly what I was thinking at this point. Targeting and other more advanced stuff seems pretty out-of-scope (or, at least, is something that can be handled manually). I was mostly hoping to align to OF semconv attributes for reporting flag state. That said, if there are relatively usable SDKs in that we can piggyback off for reading flag state from the ff service then that'd be nice.

[beeme1mr]

Is there an OpenFeature SDK for Erlang?

No, not yet. In fact, we don't have any SDKs ready for use but Java and Node is nearing an alpha state.

[beeme1mr]

Using the semantic conventions would be a great start. If timing is an issue, you should probably build your own simple solution and we can circle back later. I would be interested in adding more advance feature flagging use cases to this demo app because it would be a great way to show the value of feature flagging on a distributed trace.

[tsloughter]

great way to show the value of feature flagging on a distributed trace.

That would be neat.

I'll keep going ahead with what we have now. I'll try to check on OpenFeature from time to time, but would be great if you could let us know here when there is more development that we could start incorporating.