gRPC journey in Nuclei : Overview

Adarsh Pandey | Sun 1st Dec, 2019

Timeline

All started in Nov 2018, when we were exploring alternative of JSON format. At that time we explored Protobuf, which looks nice to our use cases.

We also want to standardize our communication framework, as we are using micro-service based architecture (around 40+ planned micro-services at that time, having different languages Java, Go) and less overhead on CPU and memory, we finally found gRPC (build on top of HTTP/2 protocol) is best alternative.

As we already adopted Kubernetes with Istio service mesh back in Sep 2018, we have Envoy proxy in place to support gRPC load-balancing. What we need to create Proto files, compile into different languages, implement services at server side and consume it on client side.

Looks easy. But creating Hello World program to standardize for all micro-services took 2 month of iteration. We build, re-build multiple time, spend sleepless night. And finally we are in good shape…

In Jan 2019, we decided to move our Android and iOS SDK to use gRPC. As of today, all our module in gRPC.

Why gRPC?

gRPC vs REST

  1. Payload Format is one of the major difference between GRPC and REST. In most of the cases, REST messages contain JSON. Theoretically can send anything as a response, but practically for the REST system, the best practice is JSON.
  2. But on the other hand, GRPC is all about Protobuf messages. Protobuf is the best way of encoding structured data.
  3. It is much more efficient than JSON and more compressed.
  4. On the other hand, JSON is the textual format.
  5. Rest is heavily dependent on HTTP 1.1, and on the other hand, GRPC based on HTTP/2. HTTP 2 is Binary protocol, and HTTP 1.1 is Textual. Binary protocol is much efficient to parse and it’s safe.
  6. HTTP 2 is multiplexing in nature. It overcomes the Head-of-Line Blocking problem. In HTTP 1.1, where there is many request from Client, then each request are served one by one. Due to which slow request slows down all the other subsequent request. But HTTP 2 has the capability of serving the multiple request and response at the same time called MultiPlexing. While working with service-to-service communication this functionality is very useful.
  7. HTTP 2 uses header compression to reduce overhead (resolved excess time and memory problem).
  8. HTTP 2 also enables Duplex Streaming, in other words, HTTP 2 allows reading and writing simultaneously, without requiring line turnarounds. Reading and writing events are independent of each other.
  9. Polyglot (Stub can be generated in many languages e.g. Java, Go, Swift, Android, NodeJS etc.)

In this series we will update weekly, how we have done gRPC in service-to-service, in Android and in iOS. We are going to cover following real life challenges we faced at Nuclei:

gRPC Load balancing, and Ingress Gateway

  1. Health check gRPC
  2. Organization and distribution of Proto files
  3. Android gRPC implementation and SSL Pinning
  4. iOS gRPC implementation and SSL Pinning

divider

Liked it? Why not share it with others