gRPC and gRPC Reflection
intro to gRPC development
Today’s popular infrastructure is Microservices. as definition Microservice is Collection of micro services and encompass a function of business that could be built in different languages. they could communicate each other to exchange data or any other purposes.
example: there are 4 services which are product, payment, voucher, and user service. user service has ability to check token and used for services to verify user. then when client make a transaction, product will send data to payment. perhaps client has voucher code than payment will communicate to voucher service. they communicate and exchange data until transaction success. the architecture approximately like the following bellow.
The question is how they communicate each other? The API — software intermediary that allows 2 applications talk to each other. what kind of API? REST? yes, the popular one is REST. how does it work? from the case above then we need to build user client in product to call to user service, user client in payment, user client in voucher, payment client in product, client, client, client, and client on each service. how if we have thousand service? It will take a time for writing client although for example we put authentication as middleware of each service. further, what if there are changes in the main services that the client has implemented on other services? boom!!. in this article I come with another approach for how services communicate each others that is gRPC.
What is gRPC?
gRPC is open-source framework developed by google, it part of the Cloud Native Computation Foundation(CNCF) at high level it allows to define Request and Response for RPC (Remote Procedure Call) — client can directly call registered function to service. On top of it, gRPC is modern, fast, efficient, build over http2, support streaming, using protocol buffer which is language interoperability etc. let’s break down the definition in next section.
gRPC vs REST
What the different between gRPC and REST? the answer is a lot, but basically the different comes from protocol they use namely http/1x and http/2.
- REST use http/1x and gRPC use http/2
REST use http/1x to transmit data, http/1 use one TCP connection for one request. if there are much request http will create TCP connection as much as request which mean it will affect latency. gRPC use http/2 to transmit data and http/2 can use one TCP connection for many request it will reduce latency for initiating TCP connection.
- REST use data format JSON, XML, Plaintext, etc and gRPC use Binary
Google protobuf is a binary format that claim more compact than JSON. the following image show protobuf more efficient than JSON.
Protocol buffer need 37 bytes for It’s data and JSON need 133 bytes. based on research conducted by nismagnus, protocol buffer has smaller size than gzipped JSON size. it mean using protocol buffer will reduce bandwidth cost.
- Code generation
In first case in microservices, using REST we need to code client from scratch to call others services and the more service we have the more client we need to create. with gRPC we only need to define .proto file one time, and generate it using protocol buffer to specific language that we desired then to call specific function in a service then we could point to generated code from .proto file to initiate connection to server one time and simply call specific function.
what? we need to write client too to call other service? yes, but promise me, it’s not as much as use REST where we need to think about path API, create entity of response, unmarshal response to entity and many others. how if we need to change message request/response in .proto file? simply you can update message without change ordering of field of message. — more
Role Protocol Buffer in gRPC
In gRPC protocol buffer used to define message and service, then generate code from it. protocol buffer use extension .proto file to define probuf file. the following code is sample of protobuf file.
message annotation is to define object request and response payload, service to define service. inside of service is function definition that define name of function, payload request of function and response of function. other wise it can specify type of gRPC call like Unary, Client Streaming and etc. it will explain in other section. Why Protocol buffer? first, it easy to write message and service definition. The definition of the API is independent from implementation and huge amount of code can be generated to any language — officially gRPC support for 12 language but there are a lot of unofficial language like swift that can be generated from .proto file.
4 Types of API in gRPC
There are 4 types of API in gRPC that is Unary, Server Streaming, Client Streaming, and Bi-directional Streaming.
- Unary RPC
Unary is simplest type of gRPC, where client send single request and server get back with single response. the following code is example of protocol buffer with type of unary RPC.
- Server Streaming RPC
Server Streaming is client send single request to server and server get back a stream of responses after getting the client’s request. to define streaming to service, annotation stream is needed in protocol buffer file when define function.
- Client Streaming
Client Streaming is client send a stream of requests to the server instead of single request then server get back with single response. similar to server streaming RPC we need stream annotation to define streaming, but fo client streaming we put it in parameter request of function.
- Bi-directional Streaming
Bi-directional Streaming is client send a stream of request to the server while client sending request, server could send a stream of responses.
process transmit data between client and server depend on context and logic of client and server. 4 types above could be describe like the following image bellow:
gRPC Reflection
as mentioned in previous section to call service we need to make connection to server as client. This is fine in production. what if for development when we need to check detail of service and event to call functions? one of bunch the answer is gRPC reflection. combined with evans we could inspect manually gRPC API and event to automate task by scripting. it’s very simple to implement gRPC reflection with evans. first, you need to register reflection in your server then install evans then simply call port gRPC service via evans.
Conclusion
gRPC is modern approach for internal service communication. the are a lot of benefit like easy to implement, save development cost, has benefit of http/2. support streaming multi direction, support interoperability language using protocol buffer, and has a lot of tools for development like gRPC reflection with evans.
gRPC Deep Dive
- gRPC Interceptor
- gRPC with SSL
- using deadline
- combine REST with gRPC to migrate REST to gRPC little by little — gRPC Gateway.
Thanks for read my article. support me with your claps if you like my article and don’t be hesitate to give me feedback or maybe you have an idea for next article, feel free to tell me in the comment down bellow 😃
