gRPC (gRPC Remote Procedure Calls) is an open source remote procedure call (RPC) system initially developed at Google in 2015. It uses HTTP/2 for transport, Protocol Buffers as the interface description language, and provides features such as authentication, bidirectional streaming and flow control, blocking or nonblocking bindings, and cancellation and timeouts. It generates cross-platform client and server bindings for many languages.

Trend on building microservices

  • Microservices are built in different language and encompass a function of your business
  • Microservices must exchange information and need to agree on:
    1. The API to exchange data
    2. The data format
    3. The error patterns
    4. Load balancing
  • One of the popular choice for building API is REST (HTTP-JSON)

v2-43aee8a0ece93258fc6d6dc27f26ccea_1440w

Building an API is hard

  • Need to think about data model
    1. JSON
    2. XML
  • Need to think about the endpoint
    1. GET /api/v1/user/123/post/123
    2. POST api/v2/user/12/post
  • Need to think about how to invoke it and error handling
  • Need to think about efficiency of the API
    1. How much data do i get out of one call
    2. Too much/little data
  • How about latency?
  • How about scalability to 1000s of clients?
  • How about load balancing?
  • How about inter operability with many languages?
  • How about authentication, monitoring, logging?

What’s gRPC

  • gRPC is a free and open-source framework developed by Google
  • gRPC is part of the Cloud Native Computation Foundation
  • At a high level, it allows you to define REQUEST and RESPONSE for gRPC (Remote Procedure Calls) and handles all the rest for you
  • On top of it, it’s modern, fast, and efficient, build on top of HTTP/2, low latency, support streaming, language independent, and makes it super easy to plug in authentication, load balancing, logging and monitoring.

What’s an RPC

  • An RPC is a Remote Procedure Call
  • In your Client code, it looks like you’re just calling a function directly on the Server
  • It’s not a new concept (CORBA had this before)
  • With gRPC, it’s implemented very cleanly and solves a lot of problem

Concept Diagram

Server Code (any other language)

1
2
3
4
//function creating users
def CreateUser(User user) {
	....
}

Client Code (any other language)

1
2
3
4
5
{code}
...
server.CreateUser(user)
...
{code}

How to get started?

  • At the core of gRPC, you need to define the messages and service using Protocol Buffers.
  • The rest of the gRPC code will be generated for you and you’ll have to provide an implementation for it.
  • One .proto file works for over 12 programming languages (server and client), and allows you to use a framework that scales to millions of RPC per seconds.

Why Protocol Buffers?

  • Protocol Buffers are language agnostic
  • Code can be generated for pretty much any language
  • Data is binary and efficiently serialized (small payloads)
  • Very convenient for transporting a lot of data
  • Protocol Buffers allows for easy API evolution using rules
  • Easy to write message definition
  • The definition of the API is independent from the implementation
  • A huge amount of code can be generated, in any language, from a simple .proto file
  • The payload is binary, therefore very efficient to send / receive on a network and serialize / de-serializer on CPU
  • Protocol Buffers defines rules to make an API evolve without breaking existing clients, which is helpful for micro-services

Protocol Buffers role in gRPC

  • Protocol Buffers is used to define:
    1. Message (data, request and response)
    2. Service (Service name and gRPC endpoints)
  • gRPC will generate code from it

Efficiency of Protocol Buffers over JSON

  • gRPC uses Protocol Buffers for communications
  • Parsing JSON is actually CPU intensive (because the format is human readable)
  • Parsing Protocol Buffers (binary format) is less CPU intensive because it’s closer to how a machine represents data
  • By using gRPC, the use of Protocol Buffers means faster and more efficient communication, friendly with mobile devices that have a slower CPU

gRPC can be used by any language

  • Because the code can be generated for any language, it makes it super simple to create micro-services in any language that interact with each other

Pros and Cons of Protocol Buffers

Advantages:

  • Data is fully typed
  • Data is compressed automatically (less CPU usage)
  • Schema (defined using .proto file) is needed to generate code and read the data
  • Documentation can be embedded in the schema
  • Data can be read across any languages
  • Schema can evolve over time, in a fast manner (schema evolution)
  • 3-10x smaller, 20-100x faster than XML
  • Code is generated for you automatically

Disadvantages

  • Protocol Buffers support for some languages might be lacking (popular ones are covered)
  • Can’t open the serialized data with a text editor because it’s compressed and serialized.

Four Types of API in gRPC

  1. Unary
  2. Server Streaming
  3. Client Steaming
  4. Bi Directional Steaming

types

  • Unary is what a traditional API looks like (HTTP REST).
  • HTTP/2 as we’ve seen, enables APIs to now have streaming capabilities.
  • The server and the client can push multiple messages as part of one request.
  • In gRPC, it’s very easy to define these APIs.

This is the end of post