- Trend on building microservices
- Building an API is hard
- What’s gRPC
- What’s an RPC
- How to get started?
- Why Protocol Buffers?
- Protocol Buffers role in gRPC
- Efficiency of Protocol Buffers over JSON
- gRPC can be used by any language
- Pros and Cons of Protocol Buffers
- Four Types of API in gRPC
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.
- Microservices are built in different language and encompass a function of your business
- Microservices must exchange information and need to agree on:
- The API to exchange data
- The data format
- The error patterns
- Load balancing
- One of the popular choice for building API is REST (HTTP-JSON)
- Need to think about data model
- Need to think about the endpoint
- Need to think about how to invoke it and error handling
- Need to think about efficiency of the API
- How much data do i get out of one call
- 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?
- 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
RESPONSEfor 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.
- 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
//function creating users
- 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.
.protofile works for over 12 programming languages (server and client), and allows you to use a framework that scales to millions of RPC per seconds.
- 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
- 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 is used to define:
- Message (data, request and response)
- Service (Service name and gRPC endpoints)
- gRPC will generate code from it
- 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
- 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
- Data is fully typed
- Data is compressed automatically (less CPU usage)
- Schema (defined using
.protofile) 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
- Protocol Buffers support for some languages might be lacking (popular ones are covered)
openthe serialized data with a text editor because it’s compressed and serialized.
- Server Streaming
- Client Steaming
- Bi Directional Steaming
- 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