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:
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.
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.
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.
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.
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.
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:
