[Proposal] Generic GRPC Provider

[thomaspoignant]

Category of Proposal

Other

Describe your proposal

Context

In this thread, we've observed that it is challenging for open-source solutions to utilize Open Feature SDKs because there is no way to have lightweight client in a distribution that can communicate with every OpenFeature provider implementation.

This limitation compels these projects to support some form of plugins to enable users to add their desired providers.

While this approach can work with certain languages, it becomes more difficult with others (such as C++, GO, etc.) and requires adapting these products to support the usage of the providers.

Proposal

During the discussion, one idea was proposed: creating a generic GRPC provider capable of communicating with any vendor that implements the associated GRPC server for this provider.

Ideally, this generic GRPC provider should support both remote flag evaluation and local flag evaluation.

For local evaluation, we could request that the vendor also provide a standardized method for performing evaluation (an option could be to use https://jsonlogic.com/ or a similar solution).

[beeme1mr]

I think we should decouple RPC based evaluation and local eval. In this case, I would recommend we focus on RPC based evaluation because it fits nicely into the existing spec and would be straightforward to implement. We would just want to make sure to document the pros/cons of a RPC based evaluation.

[thomaspoignant]

@beeme1mr I am fine with RPC-based evaluation first, but it will not fit the requirement of all vendors. The risk is that we may have some vendors not wanting to implement the RPC-based solution because if it does not support local evaluation and it may reduce the adoption of this solution for OSS projects.

If I recall correctly launchdarkly, flagsmith, and a few others are doing local evaluation.

[AloisReitbauer]

I think, it is key to specify the data model and format first. Once we have this we can work on "bindings" for different evaluation methods.

[thomaspoignant]

@AloisReitbauer just to be sure do you want to work on the data model and format of the RPC request, or do you want to define what a feature flag format should be?

Because if we focus on RPC only, it can be straightforward and just send the parameters to the remote server and let all the logic happen in the background.

[toddbaert]

I would recommend we focus on RPC based evaluation because it fits nicely into the existing spec and would be straightforward to implement.

Because if we focus on RPC only, it can be straightforward and just send the parameters to the remote server and let all the logic happen in the background.

Agree with @thomaspoignant and @beeme1mr .

I think RPC (remove evaluation) first is the right way to go.

I would also be interested in eventually working toward an in-process-evaluation model too, in which case we'd have to define a feature flag definition format.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in next 60 days.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in next 60 days.

[github-actions[bot]]

This issue was closed automatically because there has not been any activity for 90 days. You can reopen the issue if you would like to continue to work on it.