(feature) OpenFeature providers that don't require the relay proxy. about go-feature-flag

[thomaspoignant]

Hello @jeacott1,
This is a good question and this is something I have thought about intensively before building the relay-proxy.

There is nothing in Open Feature forcing me to have the relay proxy, the reason why I decided to use the API approach was to speed up the languages coverage support, if I did not have added the relay proxy I would have to rebuild the GO Feature Flag library from scratch for every language which makes it harder to maintain and evolve in the long run.

Today we have 5 different providers available for Open Feature (JS/TS, java, go, .Net, python), and all of them are using the relay proxy.
But the GO provider can also support using the go module directly and not calling any external API (see https://github.com/open-feature/go-sdk-contrib/tree/main/providers/go-feature-flag#using-the-go-module-standalone-version).

I will happy to support exactly what you say but I see some tradeoffs that we should take into consideration:

• Being sure that the hashing method of the flag put the same user in the same bucket in all languages.
• Being sure that we develop the new features for each language at the same time.
• Being sure that the rules are evaluated the same way in all languages.

I guess for the frontend SDK this can make sense (for now the JS/TS provider is mostly here for backend), but maybe it will make sense in the long run to thing about it.

Considering all of this, I am happy to have your feedback about the decision made in the past.

[jeacott1]

@thomaspoignant thanks for your response!
For me, I'm not using 'go' anywhere. My projects are generally a mix of spring boot/legacy j2ee/.net, and ts/js/react, and the 'Open Feature' thing is very appealing to me. I didn't realise the logic was also buried in the relay, I can certainly see that maintaining multiple Open Feature providers would be work, but I can also see that every flag will require an api call. hopefully these are cached clientside for a period. It's a tricky problem for a small open source project. transpiling core logic libs from some primary source to the target langs might be an option (LLVM, gopherjs etc), but its probably more pain than its worth.