[FEATURE] Make gRPC sync's gRPC connection customizable

[cupofcat]

Requirements

Today https://github.com/open-feature/flagd/blob/main/core/pkg/sync/grpc/grpc_sync.go is very rigid in terms of how it configures the gRPC connection and its credentials. Should a sync API implementation require clients to set up connections using particular credential types, or things like custom headers, it's impossible.

My proposal to solve that would be to be extend the Sync struct to have an optional field for fully custom []grpc.DialOption that would be used by grpc.NewClient() call. This is flexible and reasonably future proof:

type Sync struct {
	(...)
+	GrpcDialOptionsOverride []grpc.DialOption
	(...)
}

func (g *Sync) Init(_ context.Context) error {
	(...)
+	if len(g.GrpcDialOptionsOverride) > 0 {
+		g.Logger.Debug("GRPC DialOptions override provided")
+		rpcCon, err = grpc.NewClient(g.URI, g.GrpcDialOptionsOverride...)
+	} else {
		// Current logic
	(...)
}

Initially, I would like to contribute functionality to the flagd Go SDK that would utilize this new option (e.g. by extending the provider with WithGrpcDialOptionsOverride() option). I will file an issue in the Go SDK once we agree on the proposed solution here.

[aepfli]

I do like the idea, but i do have follow-up questions, mainly due to knowledge gaps ;)

1. Do other languages support the same construct, like java, js, python, dotnet? and are those similar?
2. Currently we try to enable configuration via Environment Variables, to share configurations easily between different services/implementations. Can we do the same thing with the DialOptions?

generally I like the idea, but in my opinion we should avoid fragmentation, and should aim for a simple mechanism which works for most of our provider implementations. Hence i think we should investigate the Option, and try to come of with a general approach to this, not just covering GoLang

[cupofcat]

1. I believe each language has their own implementation of gRPC libraries that are slightly different (idiomatic to given language) but there are definitely parallels. I have not used gRPC with other languages than Go so can't comment on the details at the moment.
2. I don't think so. IIUC, DialOptions is, in some ways, an implementation detail of Go's gRPC library. The challenge is that, unlike the SDKs for other languages, the Go SDK for flagd shares the implementation with flagd core. What I mean by that is that flagd Go SDK, for example, when it creates a provider with in-process resolver, it explicitly uses the code in https://github.com/open-feature/flagd/blob/main/core/pkg/sync/grpc/grpc_sync.go

I agree with you in principle and, perhaps, long-term the implementation of the Go SDK for flagd should stop sharing code with flagd core. However, in the short term, in order to enable the Go SDK to connect to arbitrary sync API, changes in flagd core are also needed...

As such, I hope we can agree on this change to unblock changes in the Go SDK.

[beeme1mr]

This sounds like a reasonable approach to me. 👍