How InvokeMethodGrpcAsync Passes Request Headers More Elegantly

[zhenlei520]

Ask your question here

If InvokeMethodGrpcAsync is used, the requests from service A -> sidecar and sidecar -> B should be gRpc communication, but currently InvokeMethodGrpcAsync does not provide custom Headers, I saw a similar problem: #852, through CreateInvocationInvoker can Doing custom Haeaders, but is this too much trouble, which means InvokeMethodGrpcAsync is completely useless for me?

[zhenlei520]

If gRPC proxy is used, it means that my project will not be able to use DaprClient. I saw the example of using gRPC proxy, and I feel that it is very troublesome. #825, I need to register all service areas, in addition to the CreateInvocationInvoker method in the example, I can’t see what support DaprClient provides, and even the gRPC port information needs to be rewritten, which is too much trouble

[zhenlei520]

I think adding direct custom Headers is the easiest and most effective way, I wonder if it is reasonable to do so? If not, can you tell me why? Looking forward to hearing back soon

public async Task<TResponse> InvokeMethodGrpcAsync<TRequest, TResponse>(string appId, string methodName, TRequest data, Metadata headers, CancellationToken cancellationToken = default)
    where TRequest : IMessage
    where TResponse : IMessage, new()
{
    ArgumentVerifier.ThrowIfNullOrEmpty(appId, nameof(appId));
    ArgumentVerifier.ThrowIfNullOrEmpty(methodName, nameof(methodName));

    var envelope = new Autogenerated.InvokeServiceRequest()
    {
        Id = appId,
        Message = new Autogenerated.InvokeRequest()
        {
            Method = methodName,
            ContentType = Constants.ContentTypeApplicationGrpc,
            Data = Any.Pack(data),
        },
    };

    var options = CreateCallOptions(headers: headers, cancellationToken);

    try
    {
        var response = await this.Client.InvokeServiceAsync(envelope, options);
        return response.Data.Unpack<TResponse>();
    }
    catch (RpcException ex)
    {
        throw new InvocationException(appId, methodName, ex);
    }
}

[halspang]

@zhenlei520 - The main reason we aren't adding anything to those methods is that the Dapr runtime itself actually recommends that you use gRPC proxying instead of using the old service invocation methods. I don't think we've actually done it, but I know there has been talk of deprecating the original methods in favor of gRPC proxying.

Can you explain more about why you don't want to use gRPC proxying? Yes, the DaprClient is no longer needed for service invocation, but it would still be used for other tasks like making calls to components.

What do you mean about the gRPC port information needing to be rewritten? The proxy uses the same code as the DaprClient to get the port info so it shouldn't require any extra effort from you.

Here are the docs from Dapr about service invocation, note that they do not advocate for the old method but use proxying instead: https://docs.dapr.io/developing-applications/building-blocks/service-invocation/howto-invoke-services-grpc/

[zhenlei520]

Using the gRPC proxy can achieve the effect of authentication, but doing so means that if I want to use gRPC calls, not only the caller, but also the called service needs to be re-implemented according to the gRPC standard, but from this I understand that the use of dapr does not reduce the workload, and it also passes through a layer of sidecar transit, which is a bit uncomfortable

[chrisdaiii]

I'm having the same problem, so what's the outcome of this proposal?

After using the proxy, the process is difficult to understand, and it increases a lot of workload.
My requirement is very simple: I can pass in the request header by calling the gRPC method, without doing any other operations, and I don't care.