
In this post, we continue our talk about communication between services. Today we’re going to create gRPC server and a client for it. Also, we’ll talk about the differences between gRPC and REST.
Posts in this series:
- REST API with ASP.NET Core;
- gRPC with ASP.NET Core (this post)
gRPC
gRPC (gRPC Remote Procedure Call) is a modern RPC framework. It works over HTTP/2 only and uses proto format by default for describing an interface and messages. gRPC is a contract-first approach, so you need to create a .proto file and generate your server and client from it. All modern languages support gRPC so that you can use it in a multilanguage environment.
The best part here is that you can add gRPC to your ASP.NET Core application in a very natural way, and everything will be the same (logging, DI, authentication). I show you in the next parts how to deal with it.
Server
Now, let’s build a server. We’ll create the same blog service, as we did in the REST post, so that we can compare these two solutions.
As I said earlier, gRPC is a contract-first approach. There is a proto file for our service.
And there is a contract for REST service from the previous project.
You can see that the proto contract is shorter than OpenAPI.
After that, create a default grpc project with the following command. You can check out an example in my GitHub repo.
dotnet new grpc
I removed default service and proto file, add my Blog.proto and generate service with a build command.
Next, register BlogService in the service collection.
Also, I modified my Program.cs, because gRPC template uses TLS by default, but I don’t want it in my development environment. Here is the article about configuring HTTP in ASP.NET Core across different platforms.
That’s all we need, let’s test our server. There is a handy tool for doing that called BloomRPC. If you are familiar to Postman, this tool is similar to it in the gRPC world.


Client
It’s time to build a client. I used the same worker template as in the previous post. To continue with, I added some nuget libraries and proto file to the client project.
After that, I registered BlogClient and added this line AppContext.SetSwitch("System.Net.Http.SocketsHttpHandler.Http2UnencryptedSupport", true); to call insecure gRPC services.
And there is our worker.
Let’s make some calls.

Our server and client are done. As you can see, the creation of grpc communication is relatively simple. And this is great because you don’t need to make great efforts to learn a new approach. Everything will seem very similar.
Streaming
The more advanced scenario is streaming. gRPC allows you to perform server-to-client, client-to-server and bidirectional streaming. For example, a client sends a request and receive a number of messages. It may be more efficient in the case of transferring a large amount of data or server’s pushes.
I show you modifications that need to be done to implement gRPC streaming. Firstly, add stream to your contract instead of repeated.
Secondly, modify BlogService and put a delay to simulate some work.
Finally, change the client. I use new async streams to receive articles from the server.
With the following screenshot, you can see that messages arrive at the client with a delay.

Summary
In this post, I showed how to implement communication through gRPC in ASP.NET Core application. gRPC was designed for services calling, and it does its work pretty well. There are some fascinating features like streaming, backward compatibility, deadlines, error status codes, and they help you to be more productive. I didn’t tell you about most of them, because it is a basic post and they are well described in the documentation. There are also some drawbacks. For example, gRPS isn’t fully supported by browsers, and all messages are binary, so you need a tool to understand them while debugging.
You may think that gRPC is more efficient than REST, but it is not so simple. There are different benchmarks over the internet and in some scenarios REST is better. Eventually, if you need such a performance, maybe, you should refuse remote calls at all.
To summarize, gRPC is not a silver bullet, but it’s interesting and perspective technology in its area. You should give it a try if you’re working with microservices.