Brief

This project done with Postman captures my role in building a product experience from 0-1 to make gRPC, an open-source API technology, accessible to developers via GUI.

In a small team of three, I took up the role of a design engineer, with the responsibility to understand the technology thoroughly, form assumptions about the common behavior patterns in gRPC API development and design a generic tool that responds to those patterns while also being extensible to the advanced and uncommon use cases that the protocol supports.

The gRPC API client interface

My role

Design Engineer / Technologist

Project span

4 months for two iterations

Approach for a 0-1 product

Since there was no known expectation from a tool to interact with gRPC APIs, we had to imagine the interaction patterns from scratch through rapid iterations and work with a small team of engineers to build and test the ideas with gRPC developers. Given the uncertainty around the behavior patterns, our approach here was to proceed with assumptions and fine-tune the interface with the learnings from each iteration.

An analogical understanding of how gRPC works

Remote Procedure Call (RPC) protocol– a definition that got all of us scratching our heads. To imagine an interface for it, I had to first grasp its technicalities and then form a common understanding with the team regarding how it worked. I understood RPCs from prior experience and what a schema does. However, the repercussions of a protocol enforcing schema usage on both the client and server side, unlike HTTP, were new and hard to communicate.

Once done with a technical review of the protocol from official documentation, I turned to one of the unusual ways of framing it as an aid to my design process, the team and users who are not familiar with the protocol as an analogy:

Working with a schema-driven protocol is like looking at a menu and ordering at a restaurant. The menu (schema) serves as an agreement of available dishes between the customer (client) and the chef (server).

Explorations around protocol distinctions

• The schema for a gRPC client configuration can be availed through a number of channels such as a remote repository, users’ local file system or from the API service itself that can be fetched with an initial call to the same URL (server reflection).
• gRPC supports four different types of API communication, unlike HTTP, which simply sends back a response for every request made to the server–
  1. Unary- A response is received per request sent.
  2. Client streaming- After a series of messages are streamed to the server, a single response is received as an acknowledgment.
  3. Server streaming- A series of messages are received from the server for a request made.
  4. Bidirectional streaming- A persistent channel is established for uninterrupted communication until the channel is terminated.
• The pre-requisites to make a gRPC call can be more than making an HTTP call. Users have to define the service URL, the schema, the service to be called, the method to be invoked, and a payload (message) to be passed.

Explorations focused on making working with each distinction easier for developers- the client had to be flexible to support all channels of fetching a service definition (schema), has to be extensible for all communication types, and should make it easy to configure a request.

Minimum viable product (MVP)