Expose GRPCClient.protoClient about go-sdk HOT 12 CLOSED

@artursouza There are APIs that are available in the protobuf but aren't exposed as higher-level APIs in Dapr. For example, see #164, which I fixed with a proposed PR #179, but if lower-level access had been available, people would have been able to do that even before the PR is merged.
I am sure there are other situations when having access to a lower-level API may be desirable. The API is stable anyways (for Dapr v1), so there wouldn't be the risk of exposing unstable APIs.

from go-sdk.

Thanks for the context. I understand your concerns and it makes sense.

Then maybe... Could there be a way to expose a method that returns a *grpc.ClientConn object with the default options that Dapr uses and that can be passed to NewClientWithConnection? This way one could still use NewClientWithConnection but wouldn't have to instantiate the client entirely from scratch.

from go-sdk.

/cc @yaron2 @artursouza

from go-sdk.

You can already reuse an existing connection to dapr and have your own protoClient instance using the same connection with this API.

My question would be which calls you are trying to make to the "raw" sidecar API that the SDK cannot provide?

from go-sdk.

@ItalyPaleAle Would reuse a connection from the caller work for you? Then, you can create a protoClient reusing the same connection that you use to pass it into the SDK client.

The reason I am asking is that return protoClient would make this SDK gRPC specific. In the Java SDK, for example, the connection is abstracted and none of the methods are bound to HTTP or gRPC. This SDK can decide to be different but I think there is value in keeping the abstraction in the long term.

from go-sdk.

@artursouza are you referring to creating a connection in my code, then instantiating the SDK with NewClientWithConnection? I see that.

That could work, although we'd lose out on some automatic plumbing (like reading the env vars to determine the port of the Dapr sidecar). But it may be a workaround.

Just wondering, what's the reason for having support for both HTTP and gRPC? Currently the Go SDK supports gRPC only, and I thought that was a superior way to communicate with the Dapr sidecar, when available?

from go-sdk.

@artursouza are you referring to creating a connection in my code, then instantiating the SDK with NewClientWithConnection? I see that.

That could work, although we'd lose out on some automatic plumbing (like reading the env vars to determine the port of the Dapr sidecar). But it may be a workaround.

Correct.

Just wondering, what's the reason for having support for both HTTP and gRPC? Currently the Go SDK supports gRPC only, and I thought that was a superior way to communicate with the Dapr sidecar, when available?

For now, yes, gRPC is the best way to communicate. Keeping the SDK protocol independent can enable this to change in the long term. Again, the Java SDK chose to keep the communication protocol fully transparent and users can even switch between gRPC and HTTP via system properties. The Python SDK went a different path and is gRPC specific. In the short term there is no gain in keeping the abstraction but it is a one way door, once we cross that there is no (easy) way back.

from go-sdk.

/cc @yaron2 as the SDK maintainer.
/cc @berndverst FYI.

I think the logic to create a gRPC proto client to Dapr can be separate from creating the abstracted Dapr Client. So, the app can use the gRPC specific client builder method and reuse that when creating the abstract Dapr Client.

from go-sdk.

Makes sense.

I can propose a PR. I'm on vacation this week but I can do this next week or the one after, depending on how bad work is when I get back 😅

from go-sdk.

@ItalyPaleAle I can review it after you propose.

from go-sdk.

@yaron2 we would be interested in this feature and I guess it should be easy to implement. Should I open a PR?

from go-sdk.

@yaron2 we would be interested in this feature and I guess it should be easy to implement. Should I open a PR?

Sure, thanks

from go-sdk.