Since gRPC has become a first-class citizen in .NET, a lot of features have been welcomed in the platform. Some of them are the client-side load balancing, and gRPC transcoding. In this article we will have a deep-dive into both and see how these can really change the way we look at gRPC as a technology.
gRPC has been around for a while, but it has some awesome features to look at. Not only that is wonderful for point-to-point communication in microservice architecture but it also has some new features added in .NET 7 which makes you to really consider putting this in production.
gRPC transcoding
One of the biggest problems of devs when it comes to using gRPC in production is the fact that sometimes, their APIs need to be exposed externally also, or maybe to systems that don’t know how to talk gRPC.
gRPC is not suitable to be consumed by a web browser by default, and it can’t be called just like a simple HTTP API. To do that, you will need gRPC-Web or other tools, but this is not the scope of this article. Now, what if I told you that now you have the flexibility of calling a gRPC service in 2 ways?
- As a gRPC service – for downstream communication
- As a HTTP API – for external communication
gRPC transcoding allows you to also expose a gRPC service as HTTP API also. To do that on an existing service, you will need to have the latest .NET 7 SDK installed to access the features, and you’ll need to install a few things.
- Add Microsoft.AspNetCore.Grpc.JsonTranscoding package
- Enable the middleware services.AddGrpc().AddJsonTranscoding().
- Add api.proto and annotation.proto in a google/API folder in your project.
Now, if you wonder why you need to do all this manual work, is it because .NET 7 is still in preview. Hopefully, when it reaches maturity we won’t have to add this by hand.
If we look at the example below, starting from a simple method definition inside a gRPC service you can make it callable from the browser, by making It behave like an HTTP API.
service Greeter {
rpc SayHello (HelloRequest) returns (HelloReply) {}
}
}
service Greeter {
rpc SayHello (HelloRequest) returns (HelloReply) {
option (google.api.http) = { get: "/v1/greeter/{name}" };
}
}Just by adding the option, you are instructing the platform that you want to expose that particular method as a GET request, under /v1/greeter/{name} path. The name parameter will be bound from the existing route, following the conventions we are used to already.
If you run your project and everything works fine, you should see a screen like the below, where accessing the path in the browser, or a tool like Postman, will get you a result.
gRPC transcoding runs inside the ASP NET core app, and it is super simple. It deserializes JSON messages into protobuf messages and invokes the gRPC service directly. There isn’t a third party tool involved that you need to manage. Besides that, everything happens in-process, which brings some performance benefits. One thing to note is that while gRPC supports 3 types of streaming (server, client and bi-directional), gRPC transcoding supports only server streaming.
This is not a showstopper since you wouldn’t have any kind of streaming in your HTTP APIs anyways. To make a single simple request to an API would cover most of the business cases.
To summarize, considering using gRPC in production for downstream communication and you also need to expose it to the outside world – to be consumed as a regular API- now you can do that directly from .NET by using gRPC transcoding.
gRPC clientside load balancing
When we look at a system and how that system should behave in production, we often rely on infrastructure or a tool that makes the actual load balance.
Well, grpc in .NET allows you to configure 2 types of load balancing policies:
- Static – where you know the ports
- DNS based
In the next example, you will see how you specify the addresses of the servers.
var factory = new StaticResolverFactory(addr => new[]
{
new BalancerAddress("localhost", 5000),
new BalancerAddress("localhost",5002)
});
Next, you will need to register and pass the factory
var services = new ServiceCollection();
services.AddSingleton<ResolverFactory>(factory);
Once you did this, when you create the gRPC channel, you need to pass the GrpcChannelOption object, which contains policies that you want to configure.
var channel = GrpcChannel.ForAddress(
"static:///localhost",
new GrpcChannelOptions
{
Credentials = ChannelCredentials.Insecure,
ServiceConfig = new ServiceConfig
{
LoadBalancingConfigs = { new RoundRobinConfig() }
},
ServiceProvider = services.BuildServiceProvider()
});
In our case, LoadBalancingConfigs contains RoundRobindConfig(), or you can use PickFirstConfig(), or you can even create your own if you find yourself needing something else.
What this will do, is that whenever a request is made, it will be routed to one of the servers in the load balancing. In our case, we have localhost, ports 5000 and 5001.
Request request = new Request() { ContentValue = "Joberty" };Summary
If you doubt if you should use gRPC in production or not, now you have two more reasons to try and use it. .NET 7 shines through many things, and gRPC is one of these. gRPC brings performance, stability and by using client-side load balancing you can leverage some built-in load balancing. More than this, if you find yourself in the position of needing to expose an internal service, to an external consumer, you can do that by using gRPC transcoding.
