DEV Community: Shyam Bhattarai

A Primer on Mocking gRPC services with Postman

Shyam Bhattarai — Tue, 08 Aug 2023 10:59:48 +0000

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.

Grafana for real time JMeter test monitoring

Shyam Bhattarai — Thu, 24 Oct 2019 04:31:03 +0000

Motivation

The JMeter tests run are run in a periodic basis as part of the
scheduled performance tests. The test reports including various metrics
and details are generated after the completion of the test run. It would
be advantageous to the team if the test status could be monitored in
real time so that any evidence of a correlation between the failing
components could be established.

Architecture

Telegraf : Collects the server metrics via an installed agent and stores it in InfluxDB backend

JMeter : Sends the test stats to InfluxDB using BackendListener listener

InfluxDB : Stores the metrics collected

Grafana : Finally, these metrics are visible via Grafana dashboards

Introduction

Grafana is an open source, real time metrics visualization tool
which supports a plethora of data
sources
including InfluxDB, Elasticsearch, MySQL, MSSQL, etc. The tool can
either be ran locally or can be hosted in Grafana
Cloud as well. For this
documentation, we will be looking at the steps to install the tool
locally and add other dependencies along the way. There is a nice
collection of visualization options to show the metrics which are highly
customizable.

Installation

Grafana

Latest version of Grafana can be installed from
here which also provides the option to
install it locally or use it in a hosted environment. After the
download is complete, the service should up and Grafana should be
available at http://localhost:3000.

InfluxDB

After Grafana is successfully installed, the next step is to install
the backend service, which in this case is InfluxDB. InfluxDB is an
open source time series
database which is
optimized for time-stamped series data and can be downloaded from
here. After the
installation is complete, the folder structure is created as follows:

Among these files, ‘influx.exe’ is a CLI used to execute Influx Query
Language (InfluxQL) commands and navigate the database. The
‘influxd.exe’ application is used to launch the InfluxDB server. The
‘influxdb.conf’ file is the config file that can be edited to
configure the features. It can also be installed and run as a Windows
service. The server needs to be up in order to access the database.
InfluxDB also provides an http endpoint to allow interaction with the
database. In order to enable it, the ‘influxdb.conf’ file needs to be
edited with the changes below :

Fig. Enabling the HTTP endpoint service and setting up the port address

This enables the endpoint service. This can be verified with the
PowerShell command ‘curl http://localhost:8086/ping’. The result
should be as below :

Fig.Verifying that the InfluxDB endpoint is active

First, a database needs to be created in InfluxDB to hold the sample
data from JMeter. To do this, first the influx CLI needs to be opened.

Fig.Starting the InfluxDB CLI

Typing in ‘influx’ will run the InfluxDB CLI. ‘show databases’ can
be used to view the existing databases. Currently, there should be just
one database with the name ‘_internal’. This database holds
information pertaining to InfluxDB itself and is auto-generated during
the installation. The command to create a new database is ‘create
database <database-name>’.

The database is created as follows, where the database name is set up as
jmeterStress.

Fig.Creating a new database

Configurations

There are a couple of configurations which needs be done on JMeter as well as Grafana in order to generate the measurements and display the live results.

JMX Configuration

Since, the test data needs to be written to the InfluxDB in real-time, a
‘Backend Listener’ needs to be added to the existing test plan. A
plugin
‘JMeter-InfluxDB-Writer’
needs to downloaded in order to write the data to InfluxDB so that the
Grafana JMeter dashboard can integrate seamlessly without much
configuration being needed.

Below are the steps to configure the backend listener in JMeter:

Add the Backend Listener to the test plan
Configure the Backend Listener as follows:
Fig.Configuring the BackendListener options in JMeter
‘testName’ is the name of the test.

‘influxDBHost’ and ‘influxDBPort’ are set as according to the
InfluxDB host and port addresses.

‘influxDBUser’ and ‘influxDBPassword’ are the user credentials
for the InfluxDB.

‘influxDBDatabase’ is the target DB to store the data.

Linking Grafana and InfluxDB

Now that InfluxDB and Grafana are set up, the connection between the two
needs to be established as well. Below are the steps to achieve this :

Add datasource

Navigate to http://localhost:3000 or wherever Grafana is being
hosted. At the start a login page is displayed where the default
username and password values are ‘admin’ and the password can be
changed after the login.

Fig.Grafana : Login page

After the login, the user is directed towards the default dashboard.
Currently, it holds the options to add a new data source, create a
new dashboard, add users, etc.

Click on ‘Add data source’ to configuration database connection.

Fig.Grafana : Default Dashboard

Then a time series database can be selected from the list of options
presented. After selecting ‘InfluxDB’ there, a configuration page
opens where the specific details can be configured.

Fig.Data source configuration in Grafana

After configuring the database details and clicking ‘Save &
Test’ button, a message saying ‘Data Source is working’ should be
displayed.

Create a Dashboard

The next step after configuring the data source is to create a
dashboard. There are plenty of options to choose here as well since
Grafana provides a great variety of dashboard template to choose
from.

This option can be selected by clicking on the ‘+’ icon at the
top-left corner of the menu and selecting ‘Import’ under the
create sub-menu. For our implementation we have used
this dashboard which
has all the basic visualization options. The dashboard can be
imported by either supplying it’s dashboard ID or it’s JSON file.

Fig.Importing the dashboard template

After the import is completed, a dashboard with empty visualizations
is generated. By default, the time period filter for which the
report is to be shown will be ‘Yesterday’ with a ‘Aggregation
Interval’ of 1 minute. The ‘Aggregation Interval’ is the interval
at which the data is fetched from the backend. Here, we change it to
1s to collect the data every second. Also, we change the time filter
from ‘Yesterday’ to ‘Last 5 minutes’ to show the latest results.

Fig.Changing the ‘Aggregation Interval’ to 1s and time filter to ‘Last 5 minutes’

Running the JMeter Tests

To verify whether the set up is successful, the JMeter test plan can
be run. As soon as the test are running, the commands below can be
used to verify if the data are getting stored in InfluxDB.

Fig.The metrics are being collected and visualized in real time’

Also, the database is collecting the metrics live from JMeter which
can be verified as below :

Fig.Verifying whether the measurements are being collected

In InfluxDB, ‘measurements’ can be thought of as tables. Each of
these measurements has a timestamped value can be queried like below :

Fig.Querying the measurement ‘virtualUsers’

Telegraf

Telegraf is an open source plugin-driven agent used to collect
server metrics. The types of metrics to be collected can be
customized by adding new plugins or editing existing ones. The goal
of using this server agent is to collect the server metrics from the
server where the application is being hosted and have them delivered
to the backend which in our case is InfluxDB which can then be
viewed live from Grafana as earlier.

Installing Telegraf as a Windows Service

Download Telegraf from the url below which will download the
packaged in a zipped format.

https://portal.influxdata.com/downloads/
Extract the contents on a destination folder. The folder should
contain a ‘telegraf.conf’ file containing the Telegraf
configurations.

Inside the config file, there are multiple options to collect the
server metrics as well as other configuration options. For example,
under the ‘[agent]’, there are options which can be configured
to select how the metrics will be collected.

For example, the ‘interval’ config option is used to set the
duration of the metric being collected.

We can leave these options as it is for now. The main focus is on the
‘outputs’ section of this config file. It is here where the output
format and destinations are specified.

For example, if the InfluxDB is being hosted locally on port 8086 and
the metrics are to be collected in a database named ‘jmeterStress’,
then the following configurations should be specified under the
[[outputs.influxdb]] section, which is an output plugin of
Telegraf.

Now that the backend details are set up, we need to specify which
metrics are to be collected. This can be set up under the
‘[[inputs.win_perf_counters]]’ plugin configuration. Some of
the common metric options are CPU usage, Process metrics, Disk time
and queues, Network metrics etc.

Details of other options are in the url below :

https://github.com/influxdata/telegraf/tree/master/plugins/inputs/win_perf_counters

Once these configurations are done the telegraf agent starts sending
out the metrics to the backend at the specified interval which can
then be shown over Grafana in a live manner.

Fig. Measurements being collected at InfluxDB from Telegraf

These metrics can then be represented in Grafana by using any one of
the available templates in the url below :

https://grafana.com/grafana/dashboards?dataSource=influxdb&search=telegraf

Fig. The server metrics being displayed in the Grafana dashboard