Before we modify the unwanted HTTP call, let's understand the data contract between microservices.

Imagine that we just created an application and that we should call a microservice to complete a task for our business. We read the microservice documentation with which we must communicate and implement a client to make the calls. When we try to integrate with the microservice, we get an error. Something in the microservice signature is not exactly the same as the documentation that was used as the basis for creating our client.

The preceding scenario is much more common than you can imagine. Microservices change all the time, and microservices signature breaks are often more common than they should be. Often, this kind of inconsistency happens within the company itself between different development teams.

Now, imagine if instead of a document being outdated, there was a common file that was used to create the server and client. Imagine if with this file all the server/client boilerplate code were no longer needed. It is exactly in this way that binary protocol traffic tools have been working.

The main advantage of using binary protocol tools for microservices is with regard to the accreditation between microservices. This means a file is created with the attributes, parameters, and methods that must be processed in the communication between two or more microservices, creating a kind of contract between microservices. In this way, the only possibility that one of the microservices does not respect or know the signature of a service is if a wrong accreditation file is used.

For the communication between RecommendationService and UsersService, let's create this contract file between microservices. We will use gRPC (https://grpc.io) for this. In our project, we will create a directory called ProtoFiles, where we will create the files that will be used for gRPC, for creation and code.

After creating the ProtoFiles directory, we will create the user_data.proto file. This file will have all the signatures required for communication.

First, we write in the file the version of protocol buffer that we will use:

     syntax = "proto3";

The service is responsible for performing the processing with the method that will be used for communication. Note that the GetUser method receives a specific type defined as a request and sends another specific type as a response:

     service GetUserData {
        rpc GetUser (UserDataRequest) returns (UserDataResponse) {}
     }

Now, let's create the type of input expected by the GetUser method. This type is composed of a 32-bit int:

    message UserDataRequest {
       int32 id = 1;
    }

Finally, we write the specific type of response:

    message UserDataResponse {
      int32 id = 1;
      string name = 2;
      string email = 3;
    }

The complete file has the following formatting:

    syntax = "proto3";
    service GetUserData {
      rpc GetUser (UserDataRequest) returns (UserDataResponse) {}
    }

    message UserDataRequest {
      int32 id = 1;
    }

    message UserDataResponse {
      int32 id = 1;
      string name = 2;
      string email = 3;
    }

Clearly, it's not a very large file, but it's definitely very powerful for what we need.

With the user_data.proto file and with the gRPC installed, we will execute the command lines necessary to create our server and our client. Remember that the server will be in Go and the client in Python.

In the same directory where the .proto file is, run the command lines on the following terminal:

     $ protoc --go_out=plugins=grpc:. *.proto
     $ python -m grpc_tools.protoc -I. --python_out=. --grpc_python_out=. user_data.proto

These two lines can create all the code necessary for communication between microservices; the first line to generate the files for Go, and the other for Python. The following are the files created after running the command lines:

    ├── user_data.pb.go
    ├── user_data_pb2.py
    └── user_data_pb2_grpc.py

The user_data.pb.go file must be sent to the UsersService directory inside the user_data folder. The microservice UsersService directory is distributed as follows:

    ├── Dockerfile
    ├── Godeps
    │   ├── Godeps.json
    │   └── Readme
    ├── Makefile
    ├── app.go
    ├── cache.go
    ├── db
    │   ├── Dockerfile
    │   ├── create.sql
    │   └── dbmigrate.go
    ├── main.go
    ├── main_test.go
    ├── models.go
    ├── user_data
    │   └── user_data.pb.go

The user_data_pb2.py and user_data_pb2_grpc.py files must be sent to the root directory of RecommendationService. The RecommendationService directory has the following constitution:

    ├── Dockerfile
    ├── __init__.py
    ├── config.yaml
    ├── models.py
    ├── requirements.txt
    ├── service.py
    ├── tests.py
    ├── user_client.py
    ├── user_data_pb2.py
    └── user_data_pb2_grpc.py