Why Don’t We Just Call it Directly with “gRPC”?
Let’s make The Coolest Distributed Applications and Services
As developers, we can join with “FAANG” (Facebook, Amazon, Apple, Netflix, and Google), one of our wanted dreams to achieve. Maybe some people around us already got that ticket, but not a few of them are still trying to get that “golden ticket.” We can get many benefits by joining one of that “Big Five” Tech companies, one of which is the latest technology in this era. Wondering how they can manage an extensive scale application with almost zero downtime makes all developers want more to join their team.
If you want to go fast, go alone
if you’re going to go far, go together
Maybe hard to get “FAANG” all secret recipes about how they manage their fantastic app, but one thing that they give to the public is their application architecture use Microservice. Microservice is one of the architecture styles with a service-oriented structure, consisting of a collection of small independent services. Each service is self-sustaining and should perform a single business capability within a bounded connection. We can get significant benefits from Microservice: Easier to build and maintain, Robust and Scalable, Continuously delivering faster than before, Resilient, Loosely Coupled, and still a lot more else.
In a team, communication is essential. How each member’s team communicates with each other should be efficient, fast, and direct. Microservice is also the same. Communication between services in Microservice architecture is a crucial thing that we need to manage. To manage Microservice, it will have an extensive operational load, but it is worth it compared to its benefits. based on this blog, Netflix put trust in gRPC for their internal services communication in their Microservice architecture. gRPC is an open-source, high-performance Remote Procedure Call (RPC) framework developed by Google that can run in any environment and language. It can efficiently connect services in and across data centers and microservice apps with pluggable support for load balancing, tracing, health checking, and authentication.
With gRPC, client services can directly call a method on a server application on a different machine and different language as if it were a local object, making it easier for you to create distributed applications and services. gRPC uses ideas by defining a service, specifying the methods to be called remotely with their parameters and return types that have been decided before in the proto file. The services implement the interface in proto and run a gRPC server to handle client calls on the server services. The clients have a stub that provides the same methods as the server services have on the client services. By default, language that gRPC uses is Protocol Buffers. Protocol buffers is the language which is developed by Google.
It’s heard so scary and complicated, but actually that just as simple as like we create Monolith Architecture. Let’s get our hands on.
Talk Less, Practice More !!
In this blog, we will make a simple application to order food with Microservice Architecture with internal communication using gRPC. Maybe request food application, but it will need many services, for example, Check Food Store and Check User Profile. From now on, we are only going to check user profiles and food stores. If you want to contribute or scale the example, just fork or send PR to this Github. Without any further ado, let’s started. Replace relative path on user data
To start this project, we should install all necessary dependencies. We need install Go, .Net, and gRPC generator. We will use Go language for server services and .Net for client services.
After install all necessary dependencies, let we create proto file. Proto File is file to define a service definition. In that file we will define all request, response, message, and direction of communication type. In this scenario, we will create 3 proto files; common, foodStore, and UserProfile.
common.proto is for defining enum and message type
foodStore.proto is for defining FoodStore service
userProfile.proto is for defining user profile service
We have created 3 proto files to define message and method type between services. Next step we will create server service for userProfile and foodStore. we will use Go language to build our server.
foodStore service is for get food store data
userProfile service is for get user data
Proto and Server are done. Last service that we need to create is Client to order food. We will use .Net to be our client service.
As we can see pictures above, we call the server method directly from the client, e.g., Monolith Architecture.
The Moment of The Truth !!
After everything is ready, we can run our app. To run our Server services, we can use :
go run main.goAnd for Client service:
dotnet runServer done, Client done, so let’s call the endpoint. You can call the API http://localhost:5000/Food/1 to test it.
http://localhost:5000/Food/1One of the Microservice benefits is that when a service goes down, we still can call the API without having the response Internal Server Error 500. Let’s close one of our Server services, userProfile server. We call it again.
Where is the ordering part? We only check data of user and food store
This application hasn’t completed yet. You can complete this application by yourself! Please contribute to this Github or fork the repo and scale it. Order to complete this app is your challenge!
If you want to explore other cool blogs of technologies, please stay tune on eCloudture Medium !!!
