* This post is the first in a series about gRPC.
Back in the 90's, when I started in this world, if you were lucky and had a computer, the only thing you could do was to work locally, playing your installed games or writing your documents in Word Perfect.
Nowadays, the opposite is true. Almost all devices are connected to some kind of network and all new developments are made with a focus on the cloud. This allows us to have less powerful machines and that all the computing power is transferred to those mega machines that Amazon, Google, Microsoft have ... but that's another story.
❝ New developments are made with a focus on the cloud ❞
Today's software is composed of services that interact with other services to achieve a more or less complex end. These services are usually small and with a very specific functionality, hence they are called microservices.
Communication between microservices is done through computer networks and, like people, processes also communicate by sending messages to each other. Software based on microservices is called distributed software. It has, as everything in this life, advantages and disadvantages that I will tell you about.
Processes can exchange messages synchronously or asynchronously:
Synchronous communication: the client process sends a message to the server process through the network and waits for a response message. An example of synchronous information exchange from everyday life would be a telephone conversation. One person asks and the other answers. All of this is synchronized and occurs in real time.
Asynchronous communication: processes exchange asynchronous messages using an intermediary known as an event broker. An example would be the exchange of information via Whatsapp. I send you a message and you reply when you can.
There is no one option better than the other. You just have to select the one that best suits your use case.
Most applications today communicate synchronously, sending a request and waiting for a more or less immediate response. Microservices are built as RESTful services, which implement resources that can be accessed and change their state through network calls and using the HTTP/2 protocol. These services are called APIs (Application Programming Interface).
For most use cases, RESTful services are quite cumbersome, inefficient and error-prone. Many times you will need the communication between your processes to be highly scalable and loosely coupled, i.e. more efficient than RESTful services. This is where gRPC comes in, which is nothing more than an inter-process communication method for building distributed applications and microservices.
Google developed gRPC and you may think that the g in gRPC refers to Google, but the meaning of the g has changed with each version. The version at the time of writing this article is 1.41 and in this version the g in gRPC stands for "goat". You can find all the meanings of the g for the different versions here.
In the next post I will explain what gRPC is and give you an example.
If you want to learn more about gRPC, here are some books that might interest you: