Developing High-Performance Services Leveraging gRPC and .NET 5

Following on my post yesterday looking at Laravel vs ASP.NET Core performance yesterday, I thought I would delve a little deeper and look at what NET 5 provides us with when it comes to exciting new features and performance improvements. If you don't know what gRPC is, I highly recommend you check out this Introduction to gRPC. In short, gRPC is a modern open source high performance RPC framework that can run in any environment. It has been around for a while but it’s built on new technologies like HTTP/2 and Protobuf (Protocol Buffers) is a method of serializing structured data. It’s platform-independent as it offers a language-neutral contract language.

Given that most web API's today leverage REST, why look at switching webservices from REST to gRPC to begin with. A Service API is, after all, simply a technique that handles the communication between two machines, such as REST (Representational State Transfer) and gRPC (Google Remote Procedure Call). Of course, there are other service API’s, each with their own advantages, but I've chosen to focus on gRPC and .NET 5.

The advantages gRPC has over REST are:

• gRPC uses Http/2 and improving the speed of your API by leveraging HTTP/2 provides a great opportunity to beat your competition.
• gRPC uses a faster binary protocol which makes it far more efficient for computers to parse.
• It allows for Multiplexing over a single connection, meaning it can handle multiple requests simultaneously without request blocking each other.
• It uses ProtoBuf which providers faster serialization/deserialization and also uses less bandwidth than other text-based formats such as JSON.
• There is fantastic tooling in .NET 5 that allows you to automatically generate boilerplate code to hide the underlying remoting complexity, thereby allowing you to focus on implementing your business logic.
• Streaming allows multiple responses to be sent to the client and even allows the client and server to support bi-directional streaming.
• It’s designed from the ground up to provide low latency and high throughput so it’s a fantastic match for implementing lightweight microservices where performance is critical.
• By implementing timeouts and cancellation, it allows the client to specify how long they are willing to wait for an RPC to complete.
• gRPC supports Inter-Process Communication so although typically calls are sent over tcp sockets, if the client and server are on the same machine, gRPC can use custom transports like Unix Sockets or Named Pipes.

If you want to look at gRPC within .NET 5, I would recommend you start at Introduction to gRPC on .NET | Microsoft Docs as a starting point.

If youre like me and you prefer diving right in, have a look at Create a .NET Core gRPC client and server in ASP.NET Core | Microsoft Docs.

From a performance point of view, if you're developing in an environment where milliseconds matter, I think its summed up best by this brilliant blog post by James Newton-King gRPC performance improvements in .NET 5 | ASP.NET Blog (microsoft.com)

I have also found in the .NET developer environment that there seems to be some confusion around using gRPC or SignalR given that both gRPC and SignalR support streaming. Its worth remembering that the key difference between them is SignalR supports broadcasting messages out to every client connected to a hub where gRPC is point-to-point only.

A lot has been based on gRPC but what does .NET 5 bring to the table. In a community run benchmark of different gRPC server implementations, .NET gets the highest requests per second after Rust, and is just ahead of C++ and Go.

Simply put, python and php are not even in the same league. A lot of this based on the fact that the .NET 5 gRPC server builds on top of Kestrel, a HTTP server written in C# that is designed with performance in mind. Kestrel is a top contender in the TechEmpower benchmarks, and gRPC benefits from a lot of the performance improvements in Kestrel automatically.