gRPC
Overview
This started out as a google project, hence the ‘g’, but the gRPC community is keen to distance itself from that. gRPC is quickly becoming a standard that getting wide adoption across the industry.
gRPC makes use of the features of HTTP/2 such as protocol buffers to remotely calls methods deployed on other resources, such as other VM’s or on different cloud services.
gRPC allows the developer to make calls to remote methods as if they are local resources, so there is no need for HTTP/REST infrastructure.
gRPC uses HTTP/2 so takes advantage of the inbuilt TLS message security.
gRPC is a protocol based service, where the user describes the methods, parameters and return objects, like swagger.
gRPC application developer, working within a company, should develop a nuget client library, so the client developer doesn’t need to know that remote calls are happening.
gRPC, Servers and Clients can be on vastly different architectures or environments.
Protocol Buffers
By default gRPC works with protocol buffers as originally defined by google, but its equally at home with JSON.
If you use Protocol Buffers then you create a simple text file with a .proto extension,
syntax = "proto3";
service Greeter {
rpc SayHello (HelloRequest) returns (HelloReply);
}
message HelloRequest {
string name = 1;
}
message HelloReply {
string message = 1;
}
Then use the protoc compiler to generate data access classes in your desired language
HTTP/2
- Compress Headers - HPACK
- Every HTTP request sends headers. HTTP/2 now compresses those headers reducing the package size
- Multiplexing
- Web pages can contain 100s of resources, in previous versions of HTTP each resource had to be requested individually in sequential order. With HTTP/2 your requests will be non blocking.
- Supported by all major browsers
- All major browsers support HTTP/2, but if your browser doesnt then the protocol will be downgraded to HTTP 1.1