In previous posts, we focused on Dapr service invocation using the HTTP protocol. Dapr, through its service invocation, can also reliably and securely communicate with other applications using gRPC. We will have a look at this other capability in this post.
We want to show how you can avoid having a dependency on another third party other than the one dealing with the transport protocol. That’s one of the advantages of Dapr, you can integrate with it just by relying on HTTP and/or gRPC. In the previous cases, with HTTP, we could do it without any dependencies. In the case of gRPC, we need to bring at least this dependency so that we can call Dapr services.
We are creating a standard console application in which we want to leverage the proto file delivered with the Dapr project to generate the C# Darp client.
We can get the Dapr proto files from the Dapr project on Github. Those files are included in the project in a Dapr folder at the root of the project. We need to include some nuget packages to be able to generate C# code from the proto files as we can see on the GrpcClient.csproj file.
Looking at the dapr.proto we see in which C# namespace the client code will be generated.
option csharp_namespace = "Dapr.Client.Autogen.Grpc.v1";
We can now use the generated client and specify which service we want to call using the
InvokeServiceRequest specifying the
Id which is the app-id of the Dapr sidecar so in our case proxy. Then, we specify that we want to call the method weatherforecastproxy, with an HTTP Get and pass the
Then we call
daprClient.InvokeService to invoke the Dapr service through the sidecars, get the response as JSON which we deserialize, and display the results.
Notice that we connect to the app-id proxy on the URI 127.0.0.1:3500 which is the gRPC port of our proxy service. We are invoking the weatherforecastproxy method on the service. The proxy service is an HTTP service that we are calling with gRPC thanks to Dapr sidecar. That proxy service is then calling the backend service also exposed through HTTP but accessible through gRPC again thanks to the Dapr sidecar.
All calls between Dapr sidecars go over gRPC for performance. Only calls between services and Dapr sidecars can be either HTTP or gRPC
You can use the start.ps1 PowerShell script if you have Windows Terminal installed, and it will display side by side both outputs in a new full-screen window. On the left is the proxy sidecar output and on the right the backend. There are some slight differences from the previous start.ps1 because we want to specify the gRPC port of the first sidecar, which is set to 3500.
Here is the output of our client.
We have seen that Dapr provides a way to communicate with other applications using gRPC and without taking any dependencies to any third-party framework.
You can get access to the code of this blog post on GitHub in the GrpcServiceToService folder.