A brief introduction to gRPC

1. gRPC
14 July 2021
Majid Alaeinia

2. 2
History
- gRPC First Release Date: August 2016
- Developed by: Google
- Stubby connect large number of microservices running within and across its
data centers for over a decade.
- In March 2015, Google decided to build the next version of Stubby and make it
open source.
- Now it is used on organization outside the google to power use cases from
microservices to the “last mile” of computing (mobile, web, and Internet of
Things)
- Google, Square, Netflix, CoreOs, CockroachDB, Cisco, Juniper

3. 3
Http/1.1 vs Http/2
- The first usable version of HTTP was created in 1997.
- In 2015 a new version of HTTP called HTTP/2 was created.
- HTTP/2 solves several problems that the creators of HTTP/1.1 did not
anticipate.
- Much faster and more efficient
- Prioritizing content during the loading process
- Multiplexing
- Server Push
- Header Compression

4. 4
Stub
- A stub in distributed computing is a piece of code that converts parameters
passed between client and server during a remote procedure call (RPC).
- Stubs can be generated in one of two ways:
- Manually
- Automatically

5. 5
gRPC Overview
Supported Languages:
- C#
- C++
- Dart
- Go
- Java
- Kotlin
- Node
- Objective-C
- PHP
- Python
- Ruby

6. 6
The main usage scenarios
- Efficiently connecting polyglot services in microservices style architecture
- Connecting mobile devices, browser clients to backend services

7. 7
Core features that make it awesome
- Idiomatic client libraries in 10 languages
- Highly efficient with a simple service definition framework
- Bi-directional streaming with http/2 based transport
- Pluggable auth, tracing, load balancing and health checking

8. 8
gRPC vs REST
Comparison Parameter REST gRPC
Protocol HTTP/1.1 (slow) HTTP/2 (fast)
Payload JSON (text, large) Protobuf (binary, small)
API contract Loose, optional (OPEN API) Strict, required (.proto)
Code generation Third-Party tools (Swagger) Built-in (protc)
Security TLS/SSL TLS/SSL
Streaming Client-Server requests only Bidirectional streaming
Browser Support Yes Limited (require grpc-web)
Community Large Small
Coupling Loosely coupled Tightly coupled

9. 9
gRPC vs REST
Advantages of REST
- Easy to understand.
- Tools for in inspection, modification, testing are readily available.
- Loose coupling between client and server makes changes relatively easy.
- There are lots of frameworks in most of the widely used languages to create
REST Api’s.

10. 10
gRPC vs REST
Pain Points of REST
- Streaming is difficult and it’s highly impossible in most of the languages.
- Duplex streaming is not possible.
- Hard to get multiple resources in single request.
- Need semantic versioning whenever the api contract needs to be changed.

11. 11
gRPC vs REST
Advantages of gRPC
- Language agnostic - High performance along with
Safety
- Provides Generators to Serialize or Deserialize - First Class Load Balancing
- Supports types and Validations - Selective message
compression
- Lesser Boilerplate code - Heavily optimized

12. 12
gRPC vs REST
Pain Points of gRPC
- No support for browsers hence cannot be used for external services.
- No url end points hence can’t be tested with postman or curl to check the
response.
- No predefined status codes and creating custom status code may end up in
conflicts.

13. 13
When to Use gRPC
- When the microservices is only internal and when one server needs to talk to the
other.
- When your internal services requires duplex streaming with high load of data.

14. 14
Service Methods in gRPC
1. Unary RPCs where the client sends a single request to the server and gets
a single response back, just like a normal function call.

15. 15
Service Methods in gRPC
2. Server streaming RPCs where the client sends a request to the server and
gets a stream to read a sequence of messages back. The client reads from
the returned stream until there are no more messages. gRPC guarantees
message ordering within an individual RPC call.

16. 16
Service Methods in gRPC
3. Client streaming RPCs where the client writes a sequence of messages and
sends them to the server, again using a provided stream. Once the client has
finished writing the messages, it waits for the server to read them and return
its response. Again gRPC guarantees message ordering within an individual
RPC call.

17. 17
Service Methods in gRPC
4. Bidirectional streaming RPCs where both sides send a sequence of
messages using a read-write stream. The two streams operate independently,
so clients and servers can read and write in whatever order they like: for
example, the server could wait to receive all the client messages before
writing its responses, or it could alternately read a message then write a
message, or some other combination of reads and writes. The order of
messages in each stream is preserved.

18. 18
Synchronous vs. asynchronous
Synchronous RPC calls that block until a response arrives from the server
are the closest approximation to the abstraction of a procedure call that RPC
aspires to. On the other hand, networks are inherently asynchronous and in
many scenarios it’s useful to be able to start RPCs without blocking the
current thread.
The gRPC programming API in most languages comes in both synchronous
and asynchronous flavors. You can find out more in each language’s tutorial
and reference documentation (complete reference docs are coming soon).

19. 19
How about an example?
https://github.com/MajidAlaeinia/grpc-go-client-server-playground