Introduction to gRPC

gRPC is a communication mechanism that was first introduced by Google, primarily to enable self-contained components within a distributed application, such as microservices, to communicate with each other easily. It was first made publicly available in 2016. Since then, it has been widely adopted by developers. Official libraries for it were written in the most popular programming languages.

gRPC stands for Google Remote Procedure Call. And, as the name suggests, its primary intention is to enable separate applications to call procedures inside each other's code remotely via the network.

Inside a single application, you would define your callable components (procedures, functions, or methods, depending on the language). By doing that, you can call them from any place within the same application. This means that you call the components of third-party libraries that you import into your application as they become part of your application once imported. But with an RPC mechanism in place, the code that calls your callable components doesn't have to be inside the same application as those components. So long as separate applications are hosted on the same network, they can be set up to call each other's endpoints in the code.

gRPC just happens to be the most widely adopted RPC mechanism. As well as being easy to set up compared to the alternatives, it's also very fast. Its communication protocol, known as Protocol Buffer, or Protobuf, enables very efficient message serialization while messages are in transit.

On top of this, gRPC runs on HTTP/2, which has many performance benefits over its predecessor, HTTP/1.1. Some of those benefits include multiplexing (working with multiple streams of data in a single request), header compression (which reduces message size), and server push (which enables messages to be sent from the server to a connected client without an explicit response from the client). gRPC utilizes these features, but it requires HTTP/2 protocol to be enabled on the network it's running on.

The key benefits of gRPC include the following:

• Highly performant due to the utilization of HTTP/2 features and a lightweight messaging mechanism.
• Multiple connection options instead of just a standard request/response mechanism available with bare HTTP.
• Easy and intuitive to set up with built-in code generators.
• Easy to write code against due to it having a strongly typed API schema that was designed to be highly readable.
• Widely adopted by developers with many existing libraries and code samples available.
• It is the de facto standard mechanism for direct communication between microservices.
• Official implementations are available on most of the popular programming languages and frameworks.
• Can enable communication between applications written in different languages.
• Has an in-built mechanism for hassle-free API versioning.

gRPC on ASP.NET Core

While gRPC has been publicly available since 2016, until 2019, it was only available on ASP.NET Core via third-party libraries, such as the Grpc.Core NuGet package. But with the release of ASP.NET Core 3.0, it was made available as one of the core components of the framework itself.

This has significantly simplified the process of setting up gRPC inside ASP.NET Core applications. As well as there being less boilerplate code to write, there is now better integration between gRPC and the .NET runtime, which improves the stability of the application.

On top of this, there are now pre-defined project templates available in Visual Studio IDE and the dotnet CLI (command-line interface) environment to allow you to initialize your projects with gRPC components that have already been enabled.

gRPC, along with existing features of ASP.NET Core, made it incredibly easy to build distributed applications by using a microservice architecture. The standard gRPC components are very easy to add to your application and the standard .NET build process will auto-generate all the relevant code for you.

As well as this, proto files, which, in gRPC, are used to define communication contracts, can be shared between the client and the server applications by using the standard library referencing mechanism of .NET, so the same proto file doesn't have to be duplicated in a separate project. Proto files can be stored in a reference library that both the client and the server applications use. Then, both of them can be updated simultaneously with the same copy of the communication contract so that no mismatches or incompatibility will accidentally be introduced.

Using gRPC in your own distributed ASP.NET Core application

We will start with the most fundamental part – step-by-step instructions on how to set up an ASP.NET Core application as a gRPC server and how to set up a .NET client that can talk to it.