A Primer on Mocking gRPC services with Postman

As part of increasing the overall developer productivity, it is a good practice to mock backend services so that the lead time to start the frontend related tasks including, UI/UX development, can proceed without much dependency of a fully functioning backend server.

Below we can see how a gRPC request can be formed via Postman.

For submitting a valid gRPC request in Postman, a service definition and the method needs to be invoked. Depending upon the service definition, extra parameters like message payloads, metadata and other details can be attached along with the request.

There are two ways of setting up the service definition in Postman. One way is by uploading a .proto file and another way is by supplying the service endpoint in the URL field.

Creating a service definition by uploading a proto file

One way how the service definition can be instantiated in Postman is by uploading the proto file physically. This can be a good way for the engineers to test the requests in case the service is not yet deployed.

For this, the proto can be uploaded as below:

Keep in mind that when the Import API button is clicked, then a new API is automatically created in the APIs section in Postman. See below that a New API collection ‘New API’ is created which has a service definition as projects.proto which is the uploaded proto in the previous step.

Maintaining a service definition by server reflection

Server-reflection is a gRPC feature allowing clients to submit requests without having to have precompiled into the client side. Basically, what that means is that, if the server has server-reflection enabled, then the client can pull the available public methods by simply sending a request to the service endpoint.

In the example below, we make a request to a Postman gRPC echo service [grpc.postman-echo.com](http://grpc.postman-echo.com) Further info about making a gRPC request using server-reflection from Postman can be found here.

Sample Request and Response

Once the service definition is available, you can click on the Invoke button to invoke the remote procedures defined by the service definition. You can click on the Use Example Messages button which prepares a mock message body that needs to be sent along with the request.

Below is the screenshot showing the mock request and response.

Connecting a repository to maintain an API Lifecycle

Even though the developer can manually feed the proto files directly to Postman, a much shorter feedback loop can be achieved by directly linking a remote repository to fetch the service definitions.

Moving along, we will see how we can link a Bitbucket repo to fetch the service definitions. This flow will allow both the backend and frontend teams to collaborate real-time. A typical use case for this flow can be thought of as below:

• The backend team prepares the proto file and pushed it to the repository
• The frontend team can fetch the proto file directly from Postman. Postman takes care of maintaining the repo status so that the service definition is always in sync with the latest changes.
• Based on the proto files, the developer can then build a mock server. The mock server is just what the name suggests. It returns random fake data based on the latest service definition in the repo. The frontend team can then utilize this endpoint to move ahead with their development tasks.

Below is the actual flow how we can fetch the service definition from the repo. We see here that after we have an active link with the repository (in this case, Bitbucket), we can see the uncommitted changes and any pending changes yet to be pulled from the remote. Please note that once the repo is connected, Postman creates a couple of internal files under .Postman folder for tracking purposes.

Creating Mock gRPC Servers

Once you have created an API (from the APIs option in the sidebar), Postman allows the users to publish the API so that it can be shared within the team.

In continuation from the example above, we will see how the user can create a mock server from the fetched service definition. While publishing the API, users need to version the APIs which is a neat feature which ensures that a proper versioning is maintained for each change in the server definition.

Now we will see how to use this published API to create a mock server and submit a valid request and receive the response as dictated by the service definition.

Using Postman to test the gRPC response

Although Postman provides immense value to the development team to cut down on the lead time needed to develop features, it can also provide many different ways to test the actual responses received from the hosted service endpoints.

Below, we will be invoking procedures and using the scripts to test the responses. The service endpoint for testing is an actual functional endpoint [projects-service.prd.svc.grepsr.net](http://projects-service.prd.svc.grepsr.net) which allows server-reflection.

Further Reading

Even though we try to maintain this doc for any upcoming updates in the future, you can get the latest information from the official Postman docs here