GRPC

• Google Remote Procedural Call

• framework for implementing RPC APIs via HTTP/2

• Uses a compact schema for data

  • compile to different languages

• Takes advantage of HTTP2

• similar to other rpc protocols which have a shared schema like cobra

Why

• There are many protocols out there

• For every protocol you need to build a client library to communicate

  • this is hard to update

• REST has a lot of hidden meta data so not as lightweight

• In Grpc everything is hidden,

Uses

• Unary RPC

  • request response

• Server streaming RPC

  • server side streaming

  • ie logging, progress of job, retrieving a large file

• Client streaming RPC

  • sending a large file to the server

• Bidirectional streaming RPC

  • chat

• inter microservice communication

  • multi language apps communicating

• For internal APIs where you don’t have to force technology choices on clients

• When efficient communication is a goal

• Real-time communication services where you deal with streaming calls

Pros

• fast and compact

  • messages smaller than json

• one client library

  • consistent usage

  • Has many features

• Cancel a http2 request

• TLS needs to be used

• Has automated code generation from the schema

Issues

• Stuck to http2

• Uses binary format (protobuff)

  • hard to inspect, not readable

  • auditing needs to be done before conversion

  • To analyze payloads, perform debugging, and write manual requests, devs must use extra tools like gRPC command line tool and server reflection protocol.

• Thick client

  • does a lot

  • reliant on it, can have bugs

• hard to integrate a proxy

• No native browser support

• Lack of maturity

  • minimal support about best practices, workarounds, and success stories

• Steeper learning curve

• similar to other rpc protocols which have a shared schema

  • everyone is tied to the schema, if one changes then everyone else has to change

  • It requires tight coupling between client and server

• It uses non standard naming and discovery which doesn't work across network boundaries, which is why SOAP and XML-RPC were invented, a way of channelling RPC over port 80/443.

• The lack of standards for caching of responses or middleware boxes for load balancing, rate limiting, deployment practices.

• Trying to "wish away" the network by abstracting it out of existence

• It doesn't solve the problem that RPC leaves the definition of the verbs (ie the procedures) and how they modify state of a common thing undefined. If I call an RP twice, what is the effect? How do I know it succeeded? What happens if it fails? etc etc

Protocol buffers

• structuring messages developed and used in inter-machine communication

How

• In a .proto text file, a schema is defined

  • how they want data to be structured

  • use numbers, not field names, to save storage

  • They can also embed documentation in the schema.

• Use a protoc compiler

  • this file is then automatically compiled into any of the numerous supported languages

• At runtime, messages are compressed and serialized in binary format

Advantages

• efficient parsing

  • Less CPU-intensive because data is represented in a binary format which minimizes the size of encoded messages

  • message exchange happens faster, even in devices with a slower CPU like IoT or mobile devices

• Schema is essential

  • ensure that the message doesn’t get lost between applications

  • its structural components stay intact on another service as well

Use of http2

• communication is divided into smaller messages and framed in binary format

  • messages compact and efficient

• Multiple parallel requests

  • supports multiple calls via the same channel

  • communication is bidirectional — a single connection can send both requests and responses at the same time

• Streaming

  • Real time communication

  • each stream is divided into frames that can be prioritized and run via a single TCP connection, thus reducing the network utilization and processing load