Typically applications rely on a REST based service design to expose functionality to consumers. In many cases this make sense due to the easy consumption model REST based services provide. JSON is the primary data format used in the description and data transmission which allows for simple tools such as the browser, postman, etc, to be used to explore and troubleshoot the service. However, REST only supports HTTP 1.1, which limits communication to a request response model, serving only one request at a time.

gRPC on the other hand, is built on HTTP 2 which means it supports streaming communication on the client and server and achieves multiplexing by serving many requests and responses simultaneously. gRPC uses Protocol Buffers to define the API as well as to transmit the data. The transmission of data is communicated using binary, resulting in 7 to 10 times faster message transmission in comparison to REST. Though the binary transmission of course is not human readable so can be hard to troubleshoot. 

Protocol Buffers are defined in a .proto file that specifies the API functions and the associated message formats. Using the proto definition, code is then generated for the client and server implementation which can be generated in a number of languages: javascript, python, go, java, etc. It’s worth noting, the client and server do not need to be written in the same language. This is a common approach in services running within Kubernetes. Many of the services within Kyma rely on gRPC communication for their interactions. Use cases requiring constant and/or large quantities of data can benefit from gRPC, such as AI, Iot, etc in addition to low bandwidth scenarios. 

With that let’s explore how a gRPC server can be externally exposed within the Kyma Runtime and consumed by clients. You can find a sample application here

https://github.com/SAP-samples/kyma-runtime-extension-samples/tree/master/grpc-python

First thing to note is the orders.proto which defines the order service. This contains two services RecordOrders and GetOrders as well as three message formats. Notice that the RecordOrders expects a stream of OrderRequests which upon completion returns the OrderSummary indicating how many orders have been created and the elapsed time. The GetOrders requires a OrderRequest to be sent, but is not used so an empty OrderRequest is acceptable, and returns a stream of messages of type OrderReply. With the orders.proto defined the protocol buffer code can be generated using one of the many available compiler plugins. For python, protoc can be used which is included in pythons grpcio-tools. Using the following command will regenerate the two existing files orders_pb2.py, containing the generated request and response classes, and orders_pb2_grpc.py containing the generated client and server classes. This would be necessary if any changes to the orders.proto were done.

python -m grpc_tools.protoc -I./ –python_out=. –grpc_python_out=. orders.proto

The client and server can then reference the API using the named methods to define the necessary code to process the API calls. Within the client a connection to the server is made by defining a channel. Since the Kyma Runtime requires an https connection it is required that grpc.secure_channel is used. This requires that we used the root certificate of the Kyma Runtime in the connection; you can download from https://www.identrust.com/dst-root-ca-x3 and save in the project direction as Kyma.pem. Note that within the server code, there is no handling of the certificate. The https termination will occur before the traffic reaches the workload running the example server. Also included in the sample is the environment variable _GRPC_TOKEN_ which is used as a basic mechanism to validate the client.

You can find the instructions for running the sample both locally and within the Kyma Runtime in the git repo. Happy exploring.