Howdy Hackers, it’s finally time to talk to you about gRPC for Common Lisp. In this post we will discuss the basics of gRPC. We will go through an example request/response flow from the perspective of the client and server. In future posts we will make a gRPC server and call it from a client.
gRPC is a general RPC framework developed by Google. It is often used to pass Protocol Buffer messages from one system to another, though an advanced user could use it to pass byte vectors. It sits over HTTP/2 and allows for bidirectional message streaming between a client and a server.
For these posts we assume some knowledge of Protocol Buffers.
Why would I use it?
gRPC allows for simple communication between clients and servers. It allows for language-agnostic message passing of complex structured objects.
First let’s look at a simple call flow for a client and server.
- Service implementor publishes a gRPC Service description and Request Message as well as a public URL.
- Client uses the URL and gRPC library to create a channel.
- Client instantiates a request object.
- Client uses Protocol Buffer generated code to call the server passing in the channel and request object.
- Server receives the request object, does required processing, and returns a response object.
- The client received a response message based on the published service descriptor.
The client and server need language specific Protocol Buffer and gRPC libraries. The language of these libraries for the client and server need not be identical. In our examples we will use qitab/grpc and qitab/cl-protobufs both written for Common Lisp.
The protocol buffer library takes care of many of the low-level details for you. Once you specify the request and response message fields protobufs provides convenient constructors in multiple languages and takes care of serialization and deserialization to the correct type for each message field.
The gRPC library is in charge of transmission of the underlying bytes from one client to server. It delegates to the Protocol Buffer library for serialization of the request and response messages.
One option to consider is bare HTTP calls, in fact this is the basic underlying of gRPC! This still leaves a system designer with the need to choose what to send over the wire. This is often JSON or XML. Then one must determine how to send over the API schema, device authentication schemes, and all the work that creating a good API requires. gRPC gives much of this for free.
gRPC has a larger market share. The ecosystem you want to with will often determine your choice of Thrift vs gRPC.
There are many different RPC frameworks, these are just the most common. Your software environmnet will often determine your framework, if you work at Google you will probably use gRPC where if you work at Facebook you’ll probably use Thrift. Also, not all languages are supported with any RPC framwork.
We now understand gRPC and its use case. We discussed the different types of libraries we need and saw a simple call flow with these libraries. In our next post we will create a gRPC server using qitab/grpc and call it.
Thanks go to Carl Gay for edits!