ASP.NET Core now enables developers to build gRPC services. gRPC is an opinionated contract-first remote procedure call framework, with a focus on performance and developer productivity. gRPC integrates with ASP.NET Core 3.0, so you can use your existing ASP.NET Core logging, configuration, authentication patterns to build new gRPC services.
This blog post compares gRPC to JSON HTTP APIs, discusses gRPC’s strengths and weaknesses, and when you could use gRPC to build your apps.
gRPC strengths
Developer productivity
With gRPC services, a client application can directly call methods on a server app on a different machine as if it was a local object. gRPC is based around the idea of defining a service, specifying the methods that can be called remotely with their parameters and return types. The server implements this interface and runs a gRPC server to handle client calls. On the client, a strongly-typed gRPC client is available that provides the same methods as the server.
gRPC is able to achieve this through first-class support for code generation. A core file to gRPC development is the .proto file, which defines the contract of gRPC services and messages using Protobuf interface definition language (IDL):
Greet.proto
// The greeting service definition.
service Greeter {
// Sends a greeting
rpc SayHello (HelloRequest) returns (HelloReply);
}
// The request message containing the user's name.
message HelloRequest {
string name = 1;
}
// The response message containing the greetings
message HelloReply {
string message = 1;
}
Protobuf IDL is a language neutral syntax, so it can be shared between gRPC services and clients implemented in different languages. gRPC frameworks use the .proto file to code generate a service base class, messages, and a complete client. Using the generated strongly-typed Greeter client to call the service:
Program.cs
var channel = GrpcChannel.ForAddress("https://localhost:5001")
var client = new Greeter.GreeterClient(channel);
var reply = await client.SayHelloAsync(new HelloRequest { Name = "World" });
Console.WriteLine("Greeting: " + reply.Message);
By sharing the .proto file between the server and client, messages and client code can be generated from end to end. Code generation of the client eliminates duplication of messages on the client and server, and creates a strongly-typed client for you. Not having to write a client saves significant development time in applications with many services.
Performance
gRPC messages are serialized using Protobuf, an efficient binary message format. Protobuf serializes very quickly on the server and client. Protobuf serialization results in small message payloads, important in limited bandwidth scenarios like mobile apps.
gRPC requires HTTP/2, a major revision of HTTP that provides significant performance benefits over HTTP 1.x:
- Binary framing and compression. HTTP/2 protocol is compact and efficient both in sending and receiving.
- Multiplexing of multiple HTTP/2 calls over a single TCP connection. Multiplexing eliminates head-of-line blocking at the application layer.
Real-time services
HTTP/2 provides a foundation for long-lived, real-time communication streams. gRPC provides first-class support for streaming through HTTP/2.
A gRPC service supports all streaming combinations:
- Unary (no streaming)
- Server to client streaming
- Client to server streaming
- Bidirectional streaming
Note that the concept of broadcasting a message out to multiple connections doesn’t exist natively in gRPC. For example, in a chat room where new chat messages should be sent to all clients in the chat room, each gRPC call is required to individually stream new chat messages to the client. SignalR is a useful framework for this scenario. SignalR has the concept of persistent connections and built-in support for broadcasting messages.
Deadline/timeouts and cancellation
gRPC allows clients to specify how long they are willing to wait for an RPC to complete. The deadline is sent to the server, and the server can decide what action to take if it exceeds the deadline. For example, the server might cancel in-progress gRPC/HTTP/database requests on timeout.
Propagating the deadline and cancellation through child gRPC calls helps enforce resource usage limits.
gRPC weaknesses
Limited browser support
gRPC has excellent cross-platform support! gRPC implementations are available for every programming language in common usage today. However one place you can’t call a gRPC service from is a browser. gRPC heavily uses HTTP/2 features and no browser provides the level of control required over web requests to support a gRPC client. For example, browsers do not allow a caller to require that HTTP/2 be used, or provide access to underlying HTTP/2 frames.
gRPC-Web is an additional technology from the gRPC team that provides limited gRPC support in the browser. gRPC-Web consists of two parts: a JavaScript client that supports all modern browsers, and a gRPC-Web proxy on the server. The gRPC-Web client calls the proxy and the proxy will forward on the gRPC requests to the gRPC server.
Not all of gRPC’s features are supported by gRPC-Web. Client and bidirectional streaming isn’t supported, and there is limited support for server streaming.
Not human readable
HTTP API requests using JSON are sent as text and can be read and created by humans.
gRPC messages are encoded with Protobuf by default. While Protobuf is efficient to send and receive, its binary format isn’t human readable. Protobuf requires the message’s interface description specified in the .proto file to properly deserialize. Additional tooling is required to analyze Protobuf payloads on the wire and to compose requests by hand.
Features such as server reflection and the gRPC command line tool exist to assist with binary Protobuf messages. Also, Protobuf messages support conversion to and from JSON. The built-in JSON conversion provides an efficient way to convert Protobuf messages to and from human readable form when debugging.
gRPC recommended scenarios
gRPC is well suited to the following scenarios:
- Microservices – gRPC is designed for low latency and high throughput communication. gRPC is great for lightweight microservices where efficiency is critical.
- Point-to-point real-time communication – gRPC has excellent support for bidirectional streaming. gRPC services can push messages in real-time without polling.
- Polyglot environments – gRPC tooling supports all popular development languages, making gRPC a good choice for multi-language environments.
- Network constrained environments – gRPC messages are serialized with Protobuf, a lightweight message format. A gRPC message is always smaller than an equivalent JSON message.
Conclusion
gRPC is a powerful new tool for ASP.NET Core developers. While gRPC is not a complete replacement for HTTP APIs, it offers improved productivity and performance benefits in some scenarios.
gRPC on ASP.NET Core is available now! If you are interested in learning more about gRPC, check out these resources:
- Read the gRPC for .NET Core documentation.
- Try out the gRPC getting started tutorial.
- Watch gRPC for ASP.NET Core, a new framework for high performance APIs, an introduction to gRPC presented at NDC Sydney.
Hello James ,
thanks for writing such a nice blog for gRPC in .net core, i have a request for you. I am looking for implementing gRPC in .NET 4.8 for a micro-service(yes for some reason i have to implement it in .NET 4.8) so will you be kind and help find a good info on this i could not find on this though related to .NET Core there plenty but not for .NET .4.8.
i really...
The gRPC team has an implementation that runs on .NET Framework: https://grpc.io/docs/quickstart/csharp/
Thanks for sharing.
Could you share more detail about Protobuf messages support conversion to and from JSON?
How to achieve it in .net core?
Cool stuff! I hand-rolled something similar, for microservice-to-microservice sync and async communication. I used JSON to serialize the payloads. Serialization was easy, deserialization was a bit tricky. I ended up adding type hints into the payload to aid the deserializer so that it knows exactly which type it is trying to deserialize. The cool part about JSON is that you can log and interrogate the payload and t-shoot should something go wrong. Also, for async...
Sounds like return of WCF!! 🙂
So, Is it provide some program model for dev the p2p applications?Is it possible for insteading the traditional tcp program model?
Remoting, WCF, gRPC, What’s the next? Why we must have the great variety of such RPC?
For those who doesn't know anything else to use them.
if you know what you doing you will already have your own way of doing things and will never ever depend on anyone else to tell you what to do or how to do it.
Someone from Google wrote something for themselves, started ringing the bell, and sheep started following, like with many "new technologies" that came past years. You don't know what to do and...
This guy gets it
🙂🙂🙂🙂🙂
You get it too.
Wish that many more truly get it and understand what really software development is about.
Then we will have way more better applications and systems. Not bloated with unnecessary things.
"If you don't know what you are doing , no language, no OS, no technology can help you with that. You will just sink deeper and deeper in mess that you are creating using new "cool" technologies." ©
Just remember word "KISS" forever....
Hi James, thank you for your article. Watching the latest ASP.NET Community Standup this morning with David Fowler and Damian Edwards they mentioned that although you can now develop gRPC solutions you need to be aware of the limited deployment options available to you for the Windows platform. I may be wrong but I think they said that you cannot, at this time, deploy gRPC on Azure App Services or behind IIS. Apparently this is...
You can host gRPC + ASP.NET Core in Kestrel. HttpSys and IIS support is coming. They require improvements to their HTTP/2 support to properly support gRPC.
If you are hosting on Azure then Kestrel in a container with AKS works. Azure App Service is not supported because there are reverse proxies and load balancers in front of App Service that use HttpSys. HTTP/2 needs to be properly supported from end to end.
Do you have any documentation about how to deploy it to AKS? Is quite hard to find something official.
Thanks very much for clarifying that James.
🙂
Great overview, thanks so much for sharing!
Context - microservices architecture leveraging Kubernetes environments needs efficient inter service communication and also support external clients esp doesn't support gRPC or simply put REST clients
Understanding (as of today) - not all clients esp browsers support gRPC
Need - expose, manage endpoints for gRPC as well as REST clients without duplication
Question - what approach/pattern you suggest so we can achieve exposing services end points to support both gRPC and REST given we would need dual support...
Bang on! I am looking forward to .NET solution for dual gRPC-Web API with minimal additional code.
We desperately need an easy to use Postman-like tool capable of mocking/human-readably-view gRPC and Protobuf traffic.
e.g a tool like BloomRPC https://github.com/uw-labs/bloomrpc
Have you tried BloomRPC? What about the app doesn’t make it a good test tool for you?
Yes. I tried it, not yet in real development, just a few tests so not every aspect was tested. Looks great, and exactly what was missing for somebody who is get used to Postman. I just wanted to promote it here so it may get more attention (urging the developers even more to continue their work)
BloomRPC is less than a year young while Protocol Buffers is almost two decades old, I contemplated using protobuf...