Skip to main content

gRPC - General Purpose Remote Procedure Call

Google has developed gRPC in 2015 and released it for the world to use. gRPC has been evolved from Stubby,  which Google has been using for all internal communication. 

gRPC is open-sourced high-performance RPC framework. It efficiently connects services across machines with pluggable support for load balancing, authentication, monitoring. It supports a wide range of programming language and it can be developed and deployed fast. Microservices architecture does support gRPC communication over service mesh and pretty efficient over REST. 

  • Client libraries in 10 programming languages. gRPC Languages
  • Bidirectional streaming and http/2 supported.
  • pluggable load balancing, auth and monitoring. 
  • Request response and streaming support are available.
  • Strongly typed message definition using Protobuf. 



gRPC work like a client-server model. The client will call the framework generated stub (client) to make a service request on a different machine. The server will take the request, execute the service code to handle the request and send back the response object. All this data comes in binary coded and proven to be efficient. 





Concept Diagram

Reference: grpc.io


gRPC uses IDL (interface definition language) using protobuf. Protobub is Google developed serializing framework.  Check here protocol-buffers. A .proto file will be generated to define message and service. Once generated we need to generate server and client code in our preferred language using protoc compiler. Compilers will generate client stub and server code in your prefered language and you can define service from there. 

Sample greeting.proto file 

// The greeter 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;
}


Implementation Types:

1. Unary RPC

This work like a simple client request-response model. The client sends a request and server send the response and closes the RPC call. 
  rpc SayHello (HelloRequest) returns (HelloReply) {}


2. Server Streaming RPC

The client sends a request and the server will send a list of responses. The server will end the RPC call with metadata. Order of response will be maintained for a single RPC call. 

  rpc ListofHelloReplies(HelloRequest) returns (stream HelloReply) {}

3. Client Streaming RPC

The client will be sending multiple request messages to the server and once requests are exhausted, the server will be sending a single response for it. 
  rpc ListofHelloMessages (stream HelloRequest) returns (HelloReply) {}

4. Bidirectional streaming RPC

The client will be sending multiple request messages to the server and the server can choose to start responding or it can wait for all the request. In response to a series of request, the server will also be sending a series of response messages. 
  rpc BidirectionHelloMessageandReply (stream HelloRequest) returns (stream HelloReply) {}




Synchronous and Asynchronous: A service request call wait for the response and does nothing is an asynchronous call. An asynchronous call, the client will not be waiting for the response and will start working on other calls. Both the flavours can be implemented based on the requirement. 



Labels:

Comments

Post a Comment

Popular posts from this blog

Car Parking Problem

There is n parking slots and n-1 car already parked. Lets say car parked with initial arrangement and we want to make the car to be parked to some other arrangement. Lets say n = 5, inital = free, 3, 4, 1, 2 desired = 1, free, 2, 4 ,3 Give an algorithm with minimum steps needed to get desired arrangement. Told by one of my friend and after a lot of search i really got a nice solution. I will post solution in comment part
3 comments
Read more

HTTP/2 : what and why

HTTP History In 1989, the hypertext transfer protocol have been invented. HTTP/1.1 has been released in 1997 and took the longest pause in evolution. In 2015, Google has redrafted its inhouse SPDY protocol to HTTP/2 to optimize the web page load time.  HTTP/1.1 Pitfalls Too heavy and big protocol. Too many parts have been added as optional led to complicating the protocols with less of usage. Since HTTP1.1 release, web technology have seen tremendous change. Page size has been increased to MBs, the number to pages increased manifolds and parallel components making HTTP calls increased too.  Each HTTP request has a separate TCP connection and its handshake does add to page load time.  Head of line blocking has slowed the page load. We can have a maximum 8 parallel connection to the same domain. Due to increase in multiple components making separate HTTP calls, this has been a bottleneck.  HTTP/2 Solution Binary framing layer: HTTP/1.1 was text-only messaging, which wa...
Post a Comment
Read more

Two numbers with minimum difference

Find the two numbers whose difference is minimum among the set of numbers. For example the sequence is 5, 13, 7, 0, 10, 20, 1, 15, 4, 19 The algorithm should return min diff = 20-19 = 1. Make an efficient algorithm, yeah best could be O(n). Not sure if i could use DP here, will post a solution tommorow. Let me know if you find a answer. Algorithm:MiniMumDiffN Get the size of array , say n. Get the range of array, range. Bucket Sort the above array. Search the above sorted array for minimum difference. This will be the minimum difference numbers. Now question comes where the range of above given array is very big. Algorithm:DivideArray Take an random element. Search for its position in array. Return the index of element. Algorithm:MiniMumDiff if array_range > MAXRANGE int mid = divideArray (arr,start,end); d1,max1 = MiniMumDiff( arr,start,mid-1); d2,max2 = MiniMumDIff(arr,mid+1,end); d3 = difference max1 and arr[mid] d4 = difference max2 and arr[mid] return minimum( d1,d2...
1 comment
Read more