gRPC

Memi Lavi
www.memilavi.com
gRPC

• Another type of Web API

• Quite unique

• Different from other types

• First need to understand the problems with REST API

leading to the development of gRPC

Problems with REST

• During the years it was found that there are three major

problems with REST:

Performance

Request-Response Only

Limited Syntax
Performance

• REST uses text-based messaging and protocols

• HTTP 1.1 is a text-based protocol

• JSON is a text-based messaging format

Performance

JSON – Clear text

Performance

• Two problems with text-based data exchange:

Large packets

Parsing

• Affect the performance of the API

Request-Response Only

• REST supports only the

Request-Response pattern

Request: Response:
/api/v1/orders/17 {“orde_date”:”2022-07-
10”,...}

REST API

Service
Request-Response Only

• Modern web apps require more types of client-server communication

Request-Response Only

• Push notifications are

becoming extremely useful

Request: Response:
/api/v1/orders/17 {“orde_date”:”2022-07-
10”,...}

REST API

Service
Request-Response Only

• Push notifications are

becoming extremely useful

Notification:
{“push_date”:”2022-07-
10”,...}

Service
Request-Response Only

• Can be implemented using:

• Polling

• Web Sockets Notification:

{“push_date”:”2022-07-
10”,...}

• Not part of the protocol

• Complex
Service
Limited Syntax

• REST was designed to run CRUD operations on entities

Create (=>POST)

Read (=>GET)

Update (=>PUT)

Delete (=>DELETE)
Limited Syntax

• Examples:

• GET /api/v1/orders/17

• DELETE /api/v1/employee/84

• POST /api/v1/telemetry

• GET /api/v1/flights?from=LHR&to=JFK&date=2022-08-05
Limited Syntax

• Not suited for running actions

• Examples:

• Start a new process

• Perform login

• Disable a device
History of gRPC

• Google developed a new web API standard for internal use

• Called Stubby

• In 2015 Google decided to build the next version of Stubby and

make it open source

• It was named gRPC

History of gRPC

• Main principles:

• Promote messages and services, not objects and reference

• Available on every popular platform

• Free & open

• Performant

• Allows streaming
gRPC Basics

• gRPC is:
Web API

Based on HTTP/2

RPC Style

Multiple Communication Styles

Uses Protobuf as Payload

gRPC Basics

Web API
The Internet

Web
.NET HTTP API Python

Not necessarily request / response…

gRPC Basics

Based on HTTP/2
• HTTP/1.1 was released in 1997

• The internet was quite different from what it’s now

• Performance problems due to large amount of data and

request/response model

• HTTP/2, released in 2015, aims to solve the problems

gRPC Basics

Based on HTTP/2
• HTTP/2 is:

• Fully compatible with HTTP/1.1

• Sticks to the main components of HTTP/1.1

• Headers, status codes, etc.

• Main difference is the connection between client and server

gRPC Basics

Based on HTTP/2

HTTP/1.1 HTTP/2

• Connection based on the • Allows streaming from both sides

Request/Response model • In addition to Request/Response
• Opens new possibilities such as
push notifications and more

What’s the What’s the

forecast for NYC? And
AndLondon?
forecast for NYC?
Rome?
Client Server Client Server
38 degrees 25
38 degrees
28
gRPC Basics

Based on HTTP/2
• Note:

• Due to the complex HTTP/2 handling in gRPC it can’t be used

from browsers

• Used mainly from native mobile apps and in the backend

• There is a workaround, we’ll discuss it later

gRPC Basics

RPC Style
• gRPC name has two parts:

• g for Google

• RPC
RPC

Remote Procedure Call

• Calling a method on the server from the client

GetWeather(“NYC”)

Client Server
38 GetWeather()
RPC

• Refresher

• REST works with entities, not methods

• gRPC calls the actual method

GetWeather(“NYC”)
GET /api/v1/weather?city=NYC
We have no idea
Client Server
what’s the
38 GetWeather() method name on
the server
Communication Styles

• gRPC supports 4 communication styles:

Unary

Client Streaming

Server Streaming

Bi-directional
Communication Styles
Unary

• Basically a request – response model

GetWeather(“NYC”)

Client Server
38 GetWeather()
Communication Styles
Client Streaming
• The client opens a connection to the server
• Sends continuous messages to the server
• Great for telemetry, chats, etc.

StoreTelemetry(“15”)
StoreTelemetry(“18”)

Client Server
StoreTelemetry()
Communication Styles
Server Streaming
• The client opens a connection to the server
• The server sends continuous messages using the connection
• Great for notifications, chat, etc.

Client New comment notification Server

Communication Styles
Bidirectional
• The client opens a connection to the server
• Both the client and the server send continuous messages using
the connection
• Great for telemetry, chat, real-time data, etc.

And
And London?
What’s the forecast for NYC?
Rome?
Client 25
38 degrees
28 Server
Protobuf

• The data format used by gRPC

• Theoretically gRPC can use other formats, but that doesn’t

happen

• A binary format

• Declares message format in a .proto file

• Generates client code in supported languages

Protobuf
Channels

• A definition of connection between client and server

• Specifies the host and port

• Has a state – connected, idle etc.

• Depends on the language used, channels can be queried for state

• ie. the Channel.State property in the .NET GRPC library

Timeout / Deadline

• Specify how long the client will wait to a response

• Timeout = Duration of time the client will wait

• Deadline = A fixed point in time until which the client will wait

• When exceeds, call is terminated and an error is returned

• Specifying timeout / deadline is language dependent

Metadata

• Information about a gRPC call

• For example: Authentication details

• Returned as a list of key-value pairs

• Language dependent

• ie. Metadata.GetAll() method in the .NET GRPC library

gRPC - Summary

Works with actions

Does not work with browsers

Request / Response + streaming

Not so easy to implement