gRPC is a remote procedure protocol from Google which is open source and programming language agnostic. It is touted to be better than REST in some aspects.
The reason why I evaluated gRPC for some of my projects is that it is built into various components of Google Cloud Platform and in the world of stream analytics REST API will not cut it. As a developer on Google Cloud Platform I was forced to understand its working.
Here is a high level overview of gRPC. Since I come from Microsoft .NET background I am going to explain it with the equivalent from some .NET component. gRPC is a remote procedure call which helps client applications call methods in remote class over HTTP protocol but in binary format.
Web Services based on SOAP protocol used XML for sending messages on HTTP protocol. XML was parsed and built a tree structure and it had its own performance limitations. Microsoft helped developers overcome this issue by introducing Windows Communication Foundation where the remote server class need not inherit or be aware of the protocol it is supposed to use for it methods’ call. The protocol decision was moved to service host class which will load the remote server class and enable it to serve request through various protocols like TCP/IP for intranet and HTTP for internet and other protocols.
I moved on to REST architecture for API development because it simplified the access of resources via uniform interface using HTTP verbs – GET, POST, PUT, DELETE. It also allowed the objects to be serialized either using XML or JSON. In some cases the JSON had advantage such as small size and faster deserializing than XML. Services like Runscope and Assertible helped the developers to automate the REST API testing. Google Cloud has Apigee service for API testing. REST APIs are tied closely to the Request – Response lifecycle. It provided an easy implementation for CRUD operations which can also be linked to HTTP status for each of them.
In the world of stream analytics and big data the REST API did not cut it because it was resource oriented rather and operation oriented. An analogy I can give is between ASP.NET and ASP.NET MVC. When ASP.NET MVC was embraced by developer community they need to shift their thinking from content oriented development in ASP.NET world to action oriented development in ASP.NET MVC. Similarly in gRPC world focus on the operation first and then the resources next.
The main feature I am interested in gRPC is the bidirectional streaming on HTTP/2. In the world of big data data is streamed to the server and the server streams the data to the client.
The components of the gRPC used in application development are the following.
- .proto file – this is similar to the service contract in WCF which outlines the messages and methods to be defined along with namespace and version of protocol buffer to use.
- Server – On the server side the methods defined in the .protofile are implemented in a concrete class. A contract C# class will be generated from the .proto file using options in Visual Studio.
- Client – On the client side the same .proto file is used to generate proxy class for the server side service. A proxy class knows what methods and messages the server class has and facilitates the call between the server and the client.
There are few other components outside of the gRPC that will help developers. The EVANS command line interface tool can help the clients discover the methods and message formats in the gRPC server class. You use this to generate documentation for your gRPC service and also can use this to generate WSDL equivalent of gRPC.
Testing the gRPC using the regulation REST API tools may not be a good choice because the HTTP status code may not have the correct status for the operation performed. gRPC has its own status codes and the testing agents must use this status code to validate the methods.
gRPC on HTTP/2 serves as a good foundation for developing microservices for wide variety of use cases beyond the CRUD operations. Google App Engine standard does not support the full capability of gRPC because the web server used in the App Engine standard supports the standard request and response cycle and does not allow streaming responses to be sent to the client.
If you are looking for set of tools to use in gRPC applications for development and testing then check this list.
Hope this post will help you evaluate gRPC for your enterprise API platforms. If you need any technical help regarding enterprise architecture design you can contact me on the live chat in this page.
Recent Comments