What is gRPC?
As web development grows in the microservices age, new problems are cropping up, and new solutions are being implemented. One of the issues is an interesting one- it's the issue of software languages, frameworks, and architectures being distinct from each other. The other is that REST APIs just aren't fast enough! Imagine that!
gRPC resurrects an old functionality called the Remote Procedure Call, or RPC. (The g is for "Google," everybody's favorite ). An RPC is a request-response message, similar to an API call between the client side and server side, without the interface. The client sends a request message to a remote server, and tells the server to execute a specified procedure. It may also supply parameters, similar to API parameters. The remote server sends a response to the client, and the application continues its process. What makes gRPC powerful is it makes remote calls as if they were a local object. On the server side, the server runs a gRPC server to handle client calls. On the client side, the client has a stub (or client stub) that provides the same methods as the server.
The client is blocked while the server is processing the call, unless the client sends an asynchronous request to the gRPC server, such as an XMLHttpRequest.
What problem does gRPC solve?
gRPC solves a few problems. You might recall how XML was superseded by JSON in REST APIs partly because XML was too bulky and restrictive? gRPC messages are 60-80% smaller than JSON messages!
gRPC also uses HTTP/2 instead of HTTP 1.1. HTTP/2 carries a host of features such as binary framing, multiplexing support, simultaneous bidirectional streaming, asynchronous streaming of large data sets, and header compression, all of which mean "gRPC goes fast."
About gRPC and microservices
gRPC is well-positioned for usage in microservices, where some of REST's eccentricities are becoming less charming to developers. One important feature is the open-source Protocol Buffer, or Protobuf for short.
Using a cross-platform Interface Definition Language (IDL), developers define a service contract for each microservice in a .proto file. From this file, the Protobuf compiler generates client and service code for the microservice contract. The contracted microservices can then share the local/remote relationship that RPCs do, and exchange messages as binary bites.
Additionally, the usage of `.proto` to negotiate service contracts means microservices developers, who are accustomed to navigating multiple languages, frameworks, and architectures to connect their microservices, have a simple, agnostic plumbing system that is faster than the old REST one.
Conclusion
gRPC shows a great deal of promise in the cloud-native, high-performance microservices realm. REST is a juggernaut that won't be replaced overnight, especially considering some companies have yet to implement internal APIs, but gRPC will likely solve a lot of problems in the future, and quickly.
