Dart/Flutter SDK

[marandaneto]

Hi, thank you for driving the open spec :)

Not sure if a community-maintained Dart SDK is desired but if so, I'm willing to be a contributor. I've started the Dart SDK as a hobby project and it's somewhat working already (It's pretty much based on the Java/.NET SDK).

Repo: https://github.com/marandaneto/openfeature-dart-sdk SDK: https://pub.dev/packages/openfeature

There's no provider besides the NoOP and Env. Var. Provider, but I'm willing to add the most used ones within the next few weeks/months.

I still have to write the spec tests, but feature-wise should be usable already.

Let me know your thoughts.

Thanks!

[beeme1mr]

Hey @marandaneto, that's great! Thanks for your interest and support. We haven't looked into a Dart SDK yet, so your contributions would be very much appreciated!

You may be interested in syncing with @toddbaert. He's been working on updating the spec to better support client-side feature flags. It would be wonderful to get your feedback on those improvements from a mobile dev perspective.

[toddbaert]

Exciting, thanks so much @marandaneto !

I suspect that a Dart SDK would be most valuable for use in clients, as @beeme1mr suggests. Is your intent? Our research and vendor collaboration leads us to believe that first-class client SDKs require a few additional APIs to meet the needs of that use-case, so we're working on enhancements to the spec. I think with your mobile experience you could be a great asset to the project here (sorry if that sounds presumptuous :sweat_smile: ).

An overview of the client-related specification enhancements can be viewed here. The OFEPs (OpenFeature enhancement proposals) might be of particular interest.

I'd be happy to meet to talk about the Dart SDK further. If you'd like you can reach out to me directly on our CNCF channel. I can also invite you to the org.

[marandaneto]

Nice, yeah it is my intent, so any Mobile related topic would be interesting to catch up on. I'll take a look at https://github.com/open-feature/ofep/issues/34 as well. I'll get some time to read the spec enhancements and digest them. I added the meetings to my cal but I can't promise to attend the next one because the day and time coincide with a few other meetings, let's see if I can move stuff around.

[toddbaert]

Hey @marandaneto ! I just wanted to highlight we recently released a new version of the spec: v0.6.0.

We believe that the last thing needed for a robust client implementation is this remaining spec PR: https://github.com/open-feature/spec/pull/171

I'd love to get your thoughts on this. as well as what was released in v0.6.0, especially WRT the potential Dart SDK.

[marandaneto]

@toddbaert ups sorry, missed this thread really. I'll take a look over the weekend, hold on.

[marandaneto]

@toddbaert Sorry for the delay, looks good to me, I like the concept of Static and Dynamic contexts.

One thing that I am missing, or just didn't get it yet.

I often used the concept of stickiness, so a gradual rollout of a feature is deterministic, if the evaluation happens on the client, it's important to make this possible, so that the same user always has the same result for a determined feature flag.

can we achieve that right now with the current spec? or should this be a follow-up?

For reference: https://docs.getunleash.io/reference/activation-strategies#gradual-rollout

[beeme1mr]

@marandaneto, stickiness can be achieved using evaluation context. We have an optional, named propertied called targeting key defined in the spec, but the evaluation context is just a map. All properties are optional because they can be set at various levels, and not all providers require it. However, the provider can require a targeting key and throw the TARGETING_KEY_MISSING error. This requirement should be clearly documented in the provider docs.

[toddbaert]

@marandaneto : @beeme1mr is :100: correct, "sticky" pseudo-random assignment is one of the reasons we define the targeting-key field.

[marandaneto]

Gotcha, that makes sense, the difference is that with openfeature, you have to do the stickiness algo yourself, but usually feature flag providers already have this built-in in the SDK, I guess it's fine since we already have the capability to do so. Maybe it'd be something that we offer built-in in the spec as well in the future. All good for now, thanks for the clarification.

[toddbaert]

Gotcha, that makes sense, the difference is that with openfeature, you have to do the stickiness algo yourself, but usually feature flag providers already have this built-in in the SDK

Most providers that exist at the moment wrap existing SDKs (or portions of them). These providers "handle the stickiness algo" by simply mapping the incoming targetingKey to their particilar user identifier, then that SDK uses it's existing stickiness algorithm on that identifier.

If somebody is implementing a provider entirely from scratch, not wrapping any existing SDK at all, you're correct that they would need to implement "stickiness" based on the targetingKey themselves, if it's a feature they want. That's what we've done with our reference implementation, flagd.

The targetingKey simply defines a "standard" identifier so that application authors and provider authors can have a single attribute to base this "stickiness" on.

[marandaneto]

@toddbaert I see, yeah I wasn't thinking about that, if people are writing providers that wrap their own SDKs, makes sense. Alright then, we are good.

Left a bit of feedback here as well https://github.com/open-feature/ofep/issues/34#issuecomment-1575528283

Do you need more feedback on something specific? wondering how else I can help with, besides my comments on this issue and https://github.com/open-feature/ofep/issues/34, the spec would cover the needs I have off the top of my head.