Background

This mono repo contains all the protocol buffer definitions for our services and serve as an inventory and documentation of the gRPC services at Pinpoint.

How things are organized

Each service has a directory with all the protobuf definitions that the service exposes via gRPC. The services are versioned by directory starting with v1. This allows us to adopt major changes to the protocol by creating new versions.

Setup

You'll need the following to generate code from this repo:

• Docker
• Golang 1.9.2+

You can run make setup to verify your installation. Run make help to get help.

How to create new definitions

For new services, create a new directory with the short name of the service under the definitions directory and a subdirectory named v1. You should place your proto files under this directory.

A template to start with:

syntax = "proto3";

option go_package = "github.com/pinpt/protobuf/pkg/NAME/v1";

package v1;

// Request represents ...
message YourRequest {
}

// YourResponse represents ...
message YourResponse {
	// optional fields here starting at field number 1
	string foo = 1;
}

Once you're happy with your definition, you can generate all the necessary files with:

make build

After you're done, commit your code and create a new release in Github.

Using the JavaScript library

Setup

You'll need two npm modules:

• npm install @pinpt/protobuf (this library)
• npm install cross-fetch (library for WHATWG Fetch library)

Browser

Include in ES6 using standard import such as:

import {Agent} from '@pinpt/protobuf';

Agent.GetLicense().then(resp=>console.log(resp)).catch(err=>console.error(err));

Node

You can require('@pinpt/protobuf') or using import (see above)

Tips and Tricks

• Document each type and each field
• Always start any custom fields in your response with 1
• Never hand edit any files located in swagger or pkg
• Once you've published a release, never change a field or field number
• Try and define objects and then reference them in your RPC request / response messages
• Use enums or messages where practical instead of application defined values unless those values are unconstrainted, unknown or dynamic
• Set the default ENUM value as the error state since the absense of the value if the default value (0)