gRPC describes itself as: gRPC is a modern open source high performance RPC framework that can run in any environment. It can efficiently connect services in and across data centers with pluggable support for load balancing, tracing, health checking and authentication. It is also applicable in last mile of distributed computing to connect devices, mobile applications and browsers to backend services. This is Part 3 of a series of three articles describing gRPC functionality.
Let’s assume that the dev teams have been asked to extend the services and there are multiple teams working on it. Often, the teams prefer a specific programming language for a certain job. Luckily, gRPC is supported by a broad range of languages. We are going to extend the service to communicate to a storage service, but this time the service will be written in Python. This simple service can be written in whatever language of choice but in order to showcase the gRPC functionality in Python we could say that it is a project specification.
As we are moving more towards distributed systems and micro-services, the way the services are communicating between each other becomes increasingly important. As you can imagine, the request-response delay is multiplied by the number micro-services running in the backend. Until recently, the industry standard was JSON over REST, which is a software architectural style that defines a set of recommendations for designing loosely coupled applications that use the HTTP protocol for data transmission.
This is the continuation of the previous blog post, where I explained the microservices architecture using GO Kit framework. I strongly recommend you to read the previous post as it gives you the insights into what I’ll cover this post. I talked already about the two layers of the onion architecture: Service and Endpoints. In this post I’ll cover the Transport layer and put everything together in the main function.