Embracing gRPC in .Net Core

It’s always interesting to delve into the protocols and services that come with a major release of a Microsoft platform like .Net. The release of .Net Core 3.0 is no different, adding native support for a relatively new, but no less important, protocol: gRPC.

Originally developed as an extension of Google’s protocol buffers serialization technology, gRPC takes the familiar remote procedure call concept and brings it to modern distributed systems development. It’s a powerful tool for linking microservices to each other, as well as for linking client applications to your back ends. Now supported by the Cloud Native Computing Foundation, gRPC is open source, with implementations across most familiar languages and platforms.

Inside gRPC

At the heart of gRPC is a service description based on protocol buffers. Remote procedure calls have always needed a way to define the service interface being targeted from a client: what it expects as a request, and what it sends as a response. These interface definitions are at the heart of gRPC. They form the foundation of the API-powered distributed computing world we’re constructing around cloud services.

Remote procedure calls have their own design patterns, and gRPC supports service descriptions for the four most common. First there’s the familiar unitary procedure call, where a single request receives a single response. Then there are two controlled streaming RPC options: one where the server sends a stream of data in response to a request, and one where a client sends a stream of data and the server sends a response. Finally, there is bidirectional streaming where both client and server send independent streams of data, which could contain multiple requests and responses.

gRPC will automatically create the client and server code needed for each end of the RPC connection, using the protocol buffers interface definition. You will need to implement the methods on the server and the calls on the client in order to implement your gRPC APIs. gRPC doesn’t limit you to either synchronous or asynchronous RPC calls; you have the option of using both. In practice you’d probably prefer to use asynchronous calls, as they’re more appropriate for modern applications using the public Internet.

Design by Contract is a key API development concept. You start with your API definition (here the protocol buffers interface definition), defining the services you’re building and the messages they support. The syntax of a protocol buffers proto file is simple enough: One line defines the service, its call, and its return. The rest of the file defines the messages used by the service.

Adding gRPC to .Net Core

The .Net Core release of gRPC, grpc-dotnet, is available from NuGet and can be used with the release version of the .Net Core 3.0 SDK. Although there have been third-party .Net gRPC implementations, this release makes gRPC a first-class .Net citizen and an important tool for building APIs in your apps. Written in C#, grpc-dotnet is easy to add to your code, either using command-line tools to build services or working in the familiar Visual Studio. The release of .Net Core 3.0 adds support for protocol buffers to Visual Studio, so you can create and edit your interface definitions in the same environment as your code. The same tools will generate client and server code as soon as you save your definition as a protobuf file.

If you want to add gRPC support to .Net Framework applications, there’s an alternative gRPC package for C# that offers many of the same APIs. Microsoft has said that this package will continue to be available, as grpc-dotnet is only for .Net Core.

The key change in .Net Core 3.0 that makes gRPC support possible is its direct support for HTTP/2. gRPC is designed to take advantage of HTTP/2 features, which weren’t supported by the default .Net Core HTTP server. That makes it easier to include gRPC support in ASP.Net Core, using it to host your microservices. On the client side, a client package builds on top of .Net’s existing HttpClient API, making it part of a growing number of packages that work with .Net’s HTTP, and now HTTP/2, support.

Getting started with gRPC-dotnet

Microsoft is developing its gRPC platform on GitHub, and much of the required documentation can be found there. Getting started is easy enough, once you’ve installed the .Net Core 3.0 SDK. First create a gRPC Service project in Visual Studio. This creates a proto file for your interface definition, as well as the code for the service. Before you build your code, you’ll need to download and install the gRPC client package, Google Proto Buffers, and the Grpc.tools package, all from NuGet. You’re now able to create your proto file and generate the gRPC service and client, before writing the code for your client and your server. If you need to change the interface definition at any time, edit the proto file, save it, and Visual Studio will generate the code for you.

If you’ve used the Windows Communication Foundation (WCF) in the past, you should find gRPC a pleasant alternative. It’s much more suitable for applications that cross data center boundaries than WCF, as it’s designed for HTTP/2 connections and nothing else, simplifying not only application architectures but also your firewall strategy. Instead of complex firewall rules you can use the Web Application Firewall in something like Azure Front Door, along with using its load balancers for scalability.

The real benefit of gRPC support in .Net isn’t that it’s easier for your code to interoperate with other services, it’s the layers of processing that it takes out of your code. You don’t have to manage serialization to JSON or XML or manage REST calls. Once you’ve defined your interface in protocol buffers everything else is handled for you. All you need to do is build your server methods and your client calls, and gRPC fills in the gap between the two end points for you, whether they’re on the same network segment or on opposite sides of the world.

Like the best remote procedures, gRPC is a way of bridging client and server in a way that treats them as a single application. Using gRPC in your microservices simplifies your overall application architecture, giving you the opportunity to separate services out at a method level. With Visual Studio automatically generating new gRPC interfaces every time you change your protobuf files, you’re able to add new services without rebuilding your entire application.