Propose a way to do inline evaluation of rules

[justinabrahms]

Evaluating flags without making API calls sounds awesome. What do you think?

[moredip]

I'm not against the idea of doing this, but am I right that this could be done as a sort of additional project on top of the core OpenFeature spec/SDK (similar to FlagD). I'm assuming it wouldn't require us to extend the provider API at all?

[dabeeeenster]

This is a super important feature and one that our customers make heavy use of. It would be great to get something designed for this use case.

I'm not sure I agree that having the ruleset engine run in the openfeature SDK, as opposed to the provider SDK, is the right approach. There is always going to be a mismatch between the set of rules that a provider offers, and that which can be easily modelled/computed within the openfeature SDK.

For example, Flagsmith offers a % split operator that divides the group based (roughly) on the % split provided. We also have SemVer operators. No doubt other providers have other even more esoteric operations for their rules. Its not going to be practically possible to support all ruleset operations across all providers. Requiring users to know what operators do or do not work specifically when using openfeature would not be a great experience.

Would a better approach be to have a much smaller interface for this feature? E.g in Flagsmith you can set the server side SDKs to run in either local or remote evaluation mode. remote being that every flag context requires an API/network call. local mode being that the SDK grabs the ruleset and refreshes it every 60 seconds. Could we not do something similar here? Then we offload the actual evaluation runtime to the provider SDK which would exist already regardless?

[justinabrahms]

To be clear, I don't think this requires any spec changes.

[justinabrahms]

For example, Flagsmith offers a % split operator that divides the group based (roughly) on the % split provided. We also have SemVer operators. No doubt other providers have other even more esoteric operations for their rules. Its not going to be practically possible to support all ruleset operations across all providers. Requiring users to know what operators do or do not work specifically when using openfeature would not be a great experience.

I'm thinking this could be represented in Json logic still. You could set some random number in a provider hook which adds a value to the context, which is then used in the percentage logic, for instance.

[dabeeeenster]

For example, Flagsmith offers a % split operator that divides the group based (roughly) on the % split provided. We also have SemVer operators. No doubt other providers have other even more esoteric operations for their rules. Its not going to be practically possible to support all ruleset operations across all providers. Requiring users to know what operators do or do not work specifically when using openfeature would not be a great experience.

I'm thinking this could be represented in Json logic still. You could set some random number in a provider hook which adds a value to the context, which is then used in the percentage logic, for instance.

This wouldnt work for flagsmith as we have an algorithm that ensures that identities/browsers are served consistent experiments (explained here).

I'm not clear what the benefit is of implementing these complex rulesets for the relevant providers in the OpenFeature SDK and not just leveraging the code that already exists in the provider SDK?

[kinyoklion]

While it may make for an exciting conversation, I think this doesn't belong in the purview of OpenFeature. This feels like implementation details within a provider. If multiple providers wanted to implement some common rule or caching libraries, then there isn't anything preventing that.

[toddbaert]

While it may make for an exciting conversation, I think this doesn't belong in the purview of OpenFeature. This feels like implementation details within a provider. If multiple providers wanted to implement some common rule or caching libraries, then there isn't anything preventing that.

~ @kinyoklion

I'm not sure I agree that having the ruleset engine run in the openfeature SDK, as opposed to the provider SDK, is the right approach. There is always going to be a mismatch between the set of rules that a provider offers, and that which can be easily modelled/computed within the openfeature SDK.

~ @dabeeeenster

I think these comments sum up my thoughts. I see in-process evaluation as a valid pattern, and I know for a fact a few vendors work that way (I won't mention them to remain as neutral as possible).

That said, it seems like something outside the purview of the current specification. If, as a community, we were interested in creating a specification for defining vendor-neutral feature flags, I think this would be pertinent. Maybe that's something we want to do, eventually.

[dabeeeenster]

I think there's probably a common denominator of 'modes' that server-side SDKs run in that would map to different provider modes. I can't speak for other projects but in Flagsmith we basically just have 'local' and 'remote'. Did we do any research across providers for this side of things originally?

[justinabrahms]

I've proposed this into the contrib repo, which feels like a way to do this given there are other providers in there. Not sure how to mark the ofep w/r/t accepted/rejected/etc?

[dabeeeenster]

I've proposed this into the contrib repo, which feels like a way to do this given there are other providers in there. Not sure how to mark the ofep w/r/t accepted/rejected/etc?

Where abouts is this @justinabrahms ?

[justinabrahms]

https://github.com/open-feature/java-sdk-contrib/pull/241