feat: introduce grpc sync for flagd

[Kavindu-Dodan]

This PR

Attempts to resolve #249 by introducing grpc sync provider to flagd.

OFEP [approved] - https://github.com/open-feature/ofep/blob/main/OFEP-flagd-grpc-sync.md

How to test/run ?

Flagd acts as the grpc client, hence you need at least a minimal mock server. For this, you can utilize this [1] server implementation.

Startup arguments of flagd now support grpc target uri. This can be provided with grpc:// , for example,

./flagd start --uri grpc://localhost:8090

Technical highlights

• GRPC protobuf definitions are available in buf [2] and are backed by the schema repository (https://github.com/open-feature/schemas)
• Initial connection must be successful (i.e- grpc server/target must be accepting connections)
• Subsequent server connection losses will not result in a runtime failure and connection re-establishment attempts will be performed

What is not included (follow up improvements)

• Connection security: This version does not enforce connection security. This will be addressed with follow-up improvements (ex:- TLS enabled connections). Hence, strongly recommends not using this version in production scenarios (fixed by feat: tls connectivity for grpc syncs  #398)
• Server implementations: This sync provider was designed to be open and connects to any server implementation. Hence there is no default server implementation. You may create your own server implementation based on grpc schemas.

[1] - https://github.com/Kavindu-Dodan/flagd-grpc-sync-server
[2] - https://buf.build/open-feature/flagd

[xvzf]

That's amazing!

[toddbaert]

I'm going to give this a try and a thorough review on Monday!

[toddbaert]

Works for me! I couple things I noted in testing:

• There's no way to change flag values in server, is there? I know this is just a toy demo server, so that makes sense, but I guess without that there's no way to test that the grpc sync gets updates appropriately? Or am I missing something in regards to how to test that?
• I see 1.6757003525209875e+09 warn grpc/grpc_sync.go:111 receivied unknown state: 41 {"component": "sync", "sync": "grpc"} in logs - not sure, but this could be a gRPC keepalive - we might not want to log every message received as a warning.
• If the server does, the connection fails and the client flagd crashes. I think we need to add elegant re-connection logic here and make this pretty resilient.

[Kavindu-Dodan]

Works for me! I couple things I noted in testing:

• There's no way to change flag values in server, is there? I know this is just a toy demo server, so that makes sense, but I guess without that there's no way to test that the grpc sync gets updates appropriately? Or am I missing something in regards to how to test that?
• I see 1.6757003525209875e+09 warn grpc/grpc_sync.go:111 receivied unknown state: 41 {"component": "sync", "sync": "grpc"} in logs - not sure, but this could be a gRPC keepalive - we might not want to log every message received as a warning.
• If the server does, the connection fails and the client flagd crashes. I think we need to add elegant re-connection logic here and make this pretty resilient.

Yeah, unfortunately, that's the downside of grpc. We need the server impl and currently, it's my toy server 😿 And the reason is simple, unlike file, crds, the server impl can be anything. It could be triggered from DB change, github workflow or anything. But maybe I can expand my server with few more use-cases 🤔

I addressed other concerns in respective comments :)

[Kavindu-Dodan]

@toddbaert I have added connection retry logic with the latest change set :) if you can do another round of review, and make sure this fits flagd standard, thne I will convert this draft to a normal PR 🙌

[skyerus]

Minor concerns, nice work :)