Chapter 6a: API first development with gRPCurl and Traffic Parrot mock gRPC service Docker containers

« Back to tutorials home

Introduction

If you are currently using gRPCurl for API testing of gRPC microservices that are run using Docker and you would like to begin using API first development to deliver features faster to customers by decoupling development teams, then this is the perfect guide for you.

To hit the ground running, you should already be familiar with the following tools and techniques.

By the end of the guide, you will have an overview of how to:

  1. Configure Traffic Parrot gRPC mocks using your existing gRPC API Proto files
  2. Save Traffic Parrot configuration as JSON files
  3. Build a Traffic Parrot Docker container
  4. Mock your gRPC dependencies by running Traffic Parrot alongside your microservice under test
  5. Test using mocks instead of real dependencies
  6. Continue to use gRPCurl to test your gRPC microservice APIs

Current development workflow

Your current development workflow without API first development may look something like this:

Team A Team B
Develops microservice Waiting weeks or months for Team A to finish
Completes development Receives Proto API specifications
Develops microservice using the real dependency
Performs final smoke tests using the real dependency
Completes development

The overall timeline for Team B is pushed out because they must wait for Team A to finish work before they can test any functionality that relies on microservice A to be ready. This schedule slip can be very significant for companies that rely on faster time to market to maintain a competitive advantage.

Target development workflow

Your target development workflow with API first development may look something like this:

Team A Team B
Both teams define the Proto API specifications together
Either team configures the Traffic Parrot mocks for Team B within days
Develops microservice Develops microservice using the Traffic Parrot mocks
Completes development Performs final smoke tests using the real dependency
Completes development

The overall timeline for Team B is pulled in because they no longer have to wait for Team A to finish work. They can get started within days of the initial Proto specification being agreed between the teams.

How to implement the target development workflow

The key difference between the current and target workflow is the use of Traffic Parrot gRPC mocks, to enable Team B to start development as soon as the Proto API specifications are agreed between Team A and Team B.

The diagram below shows the type of activities developers typically perform without an API first development approach.

Developer activities without API first development approach

The next diagram shows how these activities change with an API first development approach, adding steps to configure and run Traffic Parrot gRPC mocks instead of the real dependencies.

Developer activities with API first development approach

To prototype and configure Traffic Parrot gRPC mocks, a developer should start Traffic Parrot on their local machine using the command line start scripts. They can then use the UI to configure mocks by providing Proto files and editing request and response payload templates as required. They can test their mocks by making gRPCurl requests to the mocked API endpoints. When they are finished prototyping, the resulting JSON mapping files can be committed to Git and used in a CI pipeline to build a Docker image. This Docker image can then be used in place of the real gRPC dependencies, allowing multiple teams to work in parallel, before the real APIs are ready.

Create Traffic Parrot gRPC mock using the UI

The same Traffic Parrot Docker mocks can be reused for both local development, automated builds, CI/CD, shared environments, performance testing, training and more!

Details on how to configure Traffic Parrot can be found here:

Next steps