Intro to gRPC
Let’s start with an RPC (Remote Procedure Call) and LPC (Local procedure call, or just a procedure call) first. LPC is a plain function call within a process of the app. RPC is a protocol that allows a function / service on one machine to call a function / service on another remote machine, but as if it was a local call, abstracting the complexities of the network communication.
Because the application that uses RPC does not contain any communication code (Note. It’s possible thanks to pre-made RPC libraries which take care of communication), it is independent of:
- Particular communications protocols.
- The operating system.
gRPC
gRPC is an open-source Remote Procedure Call (RPC) framework created by Google in 2016. It appeared from a rewrite of Google internal RPC infrastructure. Many organizations have adopted gRPC as a preferred RPC mechanism: Google, Netflix, Slack, Square, Cisco. Since 2017 gRPC is part of CNCF.
There are a lot of libraries and tools that allow to implement gRPC service. You can see them on official gRPC GitHub repo.
gRPC allows to define services and message types using Protocol Buffers (protobuf). Protocol Buffers is a language-agnostic and platform-agnostic data interchange format. gRPC uses Protocol Buffers to encode and send data over the network by default.
Here are some of the features of gRPC:
- Strongly typed schema definitions, defined in
.protofile. - High-performant out of the box thanks to binary encoding Protocol Buffers format (uses less space than JSON) and use of HTTP/2, which brings all benefits of HTTP/2 (Multiplexing, Stream prioritization, Binary protocol, Server push).
- gRPC service is also defined in a
.protofile by specifying RPC methods. - Dev can generate client and server code using gRPC tooling from the
.protofiles. Thanks to the support of many languages, the client and server can independently choose the language to use.
All this allows to create high-quality and type-safe APIs efficiently.
gRPC vs REST API
gRPC and REST API are two different approaches for building distributed systems, each with its own features.
gRPC tends to be more efficient and suitable for microservices communication. REST API are more widely adopted and hence there are a lot of learning materials on the web.
In gRPC, one service calls a specific function on another server. In REST, instead of calling remote functions as local, the service sends commands (with HTTP methods GET, POST, PUT, DELETE, PATCH) to the server. This description is pretty abstract, but what matters is particular mechanics behind communication. The best way to understand it’s to try each of the two, compare them on every step. But it’s out of the scope of this article.
The choice between the two depends on the specific requirements and constraints of the project.
Finazon gRPC client libraries
Why we’ve created gRPC client libraries? In short, it’s useful for our users. Read below the details.
Simpler to use than REST API
At Finazon we’ve created clients for all major languages. All you need is to download a particular library, run routine, and get the data.
It’s faster than REST API
As described before, gRPC provides better performance due to its binary serialization (protobuf) and the capabilities of HTTP/2.
All support is on our side
All support of client libraries is on our side, we are ensuring seamless integration and great developer experience. If you are serious about data, just get use-ready and well-maintained solutions from us.
All client library gRPC methods mirror REST API reference
Each client library mirrors REST API methods.
You can contribute
We welcome and encourage contributions! We foster a collaborative environment where your expertise can make a meaningful impact. Please check our GitHub repo.
Please note, at the moment we don’t accept commits, so please just create issues and we’ll be happy to talk.
