A brief introduction to gRPC Protocol in Golang
gRPC overview for beginners using Go language
The RPC Protocol
RPC is a network programming model or interprocess communication technique used for point-to-point communications between software applications.
RPC is a protocol which one program can use to request a service from a program located in another computer without having to understand the network’s details.
The RPC stands for “remote procedure call” and it’s a form of client-server interaction — caller is a client and executor is a server — typically implemented via a request-response message-passing system.
Client runtime program has the knowledge of how to address the remote server application and sends across a network the message that requests the remote procedure. Similarly, the server includes a runtime program and stub that interface with the remote procedure itself.
. . .
How does it work?
The way RPC works is that a sender or a client creates a request in the form of a procedure, function or method call to a remote server, which RPC translates and sends. When the remote server receives the request, it sends a response back to the client and the application continues its process.
When the server processes the call or request, the client waits for the server to finish processing before resuming its process. However, the use of lightweight processes or threads, that share the same address space, allows multiple RPCs to be performed concurrently.
. . .
Protobuf (Protocol Buffers)
Protobuf or Protocol Buffers is a binary communication format by Google. It is used to serialize structured data. A communication format? Kind of like JSON? Yes. It's more than 10 years old and Google has been using it for a while now.
But don’t we have JSON and it’s so ubiquitous…
Just like Golang, Protobufs doesn’t really solve anything new. It just solves existing problems more efficiently and in a modern way. Unlike Golang, they are not necessarily more elegant than the existing solutions. Here are the focus points of protobuf:
- It’s a binary format, unlike JSON and XML, which are text based and hence it’s vastly space efficient.
- First hand and sophisticated support for schemas.
- First hand support for generating parsing and consumer code in various languages.
Binary format and speed
So are protobuf really that fast? The short answer is, yes. According to the Google Developers they are 3 to 10 times smaller and 20 to 100 times faster than XML. It’s not a surprise as it is a binary format, the serialized data is not human readable.
(Image Source: Beating JSON performance with Protobuf)
Protobufs take a more planned approach. You define `.proto` files which are kind of the schema files but are much more powerful. You essentially define how you want your messages to be structured, which fields are optional or required, their data types etc. After that the protobuf compiler will generate the data access classes for you. You can use these classes in your business logic to facilitate communication.
Looking at a `.proto` file related to a service will also give you a very clear idea of the specifics of the communication and the features that are exposed. A typical .proto file looks like this:
. . .
gRPC
gRPC, as you guessed it, is a modern RPC (Remote Procedure Call) framework. It is a batteries included framework with built in support for load balancing, tracing, health checking, and authentication. It was open sourced by Google in 2015 and it’s been gaining popularity ever since.
An RPC framework…? What about REST...?
SOAP with WSDL has been used long time for communication between different systems in a Service Oriented Architecture. At the time, the contracts used to be strictly defined and systems were big and monolithic, exposing a large number of such interfaces.
Then came the concept of ‘browsing’ where the server and client don’t need to be tightly coupled. A client should be able to browse service offerings even if they were coded independently. If the client demanded the information about a book, the service along with what’s requested may also offer a list of related books so that client can browse. REST paradigm was essential to this as it allows the server and client to communicate freely without strict restriction using some primitive verbs.
As you can see above, the service is behaving like a monolithic system, which along with what is required is also doing n number of other things to provide the client with the intended `browsing` experience. But this is not always the use case. Is it?
. . .
Enter the Microservices
There are many reasons to adopt for a Microservice Architecture. The prominent one being the fact that it is very hard to scale a Monolithic system. While designing a big system with Microservices Architecture each business or technical requirement is intended to be carried out as a cooperative composition of several primitive ‘micro’ services.
These services don’t need to be comprehensive in their responses. They should perform specific duties with expected responses. Ideally, they should behave like pure functions for seamless composability.
Now using REST as a communication paradigm for such services doesn’t provide us with much of a benefit. However, exposing a REST API for a service does enable a lot of expression capability for that service but again if such expression power is neither required nor intended we can use a paradigm that focuses more on other factors.
gRPC intends to improve upon the following technical aspects over traditional HTTP requests:
- HTTP/2 by default with all its goodies.
- Protobuf as machines are talking.
- Dedicated support for streaming calls thanks to HTTP/2.
- Pluggable auth, tracing, load balancing and health checking because you always need these.
As it’s an RPC framework, we again have concepts like Service Definition and Interface Description Language which may feel alien to the people who were not there before REST but this time it feels a lot less clumsy as gRPC uses Protobuf for both of these.
Protobuf is designed in such a way that it can be used as a communication format as well as a protocol specification tool without introducing anything new. A typical gRPC service definition looks like this:
. . .
Further reading
. . .
Conclusion
Golang, along with gRPC using Protobuf is an emerging stack for modern server programming. Golang simplifies making concurrent/parallel applications and gRPC with Protobuf enables efficient communication with a pleasing developer experience.
Write your response...
© 2024 Ednsquare hello@ednsquare.com