How to generate an OpenAPI/Swagger spec with gRPC Gateway
You may want to provide a RESTful API in addition to your gRPC service without the need to duplicate your code.
gRPC Gateway
In this tutorial, we’ll take a detailed look at how to use gRPC Gateway to generate an OpenAPI schema based on a Protocol Buffers (protobuf) gRPC service definition. Afterward, we can use Speakeasy to read our generated OpenAPI schema and create a production-ready SDK.
Tip
If you want to follow along, you can use the gRPC Speakeasy Bar example repository.
An Overview of gRPC Gateway
gRPC Gateway
This way, you can expose an HTTP endpoint that can be called by clients that don’t support gRPC. The generated server code will forward incoming JSON requests to your gRPC server and translate the responses to JSON.
gRPC Gateway also generates an OpenAPI schema that describes your API. You can use this schema to create SDKs for your API.
OpenAPI Versions
gRPC Gateway outputs OpenAPI 2.0, and Speakeasy supports OpenAPI 3.0 and 3.1. To generate an OpenAPI 3.0 or 3.1 schema, you’ll need to convert the OpenAPI 2.0 schema to at least OpenAPI 3.0.
The Protobuf to REST SDK Pipeline
To generate a REST API with a developer-friendly SDK, we’ll follow these three core steps:
-
gRPC to OpenAPI: First, we will use gRPC Gateway to produce an OpenAPI schema based on our protobuf service definition. This generated schema is in OpenAPI 2.0 format.
-
OpenAPI 2.0 to OpenAPI 3.x: Next, as gRPC Gateway’s output schema is in OpenAPI 2.0 and we need at least OpenAPI 3.0 for our SDK, we will convert the generated schema from OpenAPI 2.0 to OpenAPI 3.0.
-
OpenAPI 3.x to SDK: Finally, once we have the OpenAPI 3.0 schema, we will leverage Speakeasy to create our SDK based on the OpenAPI 3.0 schema derived from the previous steps.
By following these steps, we can ensure we have a robust, production-ready SDK that adheres to our API’s specifications.
Step-by-Step Tutorial: From Protobuf to OpenAPI to an SDK
Now let’s walk through generating an OpenAPI schema and SDK for our Speakeasy Bar gRPC service.
Check Out the Example Repository
If you would like to follow along, start by cloning the example repository:
Install Go
To generate an OpenAPI schema from a protobuf file, we’ll need to install Go and protoc.
This tutorial was written using Go 1.21.4.
On macOS, install Go by running:
Alternatively, follow the Go installation instructions
Install Buf
We’ll use the Buf CLI
On macOS, install Buf by running:
Alternatively, follow the Buf CLI installation instructions
Install Buf Modules
We’ll use Buf modules to manage our dependencies.
Install protoc-gen-go
Buf requires the protoc-gen-go
plugin to generate Go code from protobuf files.
Install protoc-gen-go
by running:
Make sure that the protoc-gen-go
binary is in your $PATH
. On macOS, you can achieve that by running the following command if the go/bin
directory is not already in your path.
Install Go Requirements
Generate the Go Code
We’ll use Buf to generate the Go code from the protobuf file.
Run the following in the terminal:
Buf reads the configuration in buf.gen.yaml
, then generates the Go code in the proto
directory.
This will generate the proto/speakeasy/v1/speakeasy.pb.go
, proto/speakeasy/v1/speakeasy_grpc.pb.go
, and proto/speakeasy/v1/speakeasy.pb.gw.go
files.
Generate the OpenAPI Schema
Because we have the openapiv2
protoc plugin configured in our buf.gen.yaml
file, Buf will generate an OpenAPI schema and save it as openapi/speakeasy/v1/speakeasy.swagger.json
.
This is the OpenAPI 2.0 schema that gRPC Gateway generates by default.
Convert the OpenAPI Schema to OpenAPI 3.0
We’ll use the excellent kin-openapi
In convert/convert.go
, we use kin-openapi
to unmarshal openapi/speakeasy/v1/speakeasy.swagger.json
, then convert it to OpenAPI 3.0, then marshal it back to JSON, and finally write it to openapi/speakeasy/v1/speakeasy.openapi.json
.
To do the conversion, run the following in the terminal:
How To Customize the API Schema
By modifying the protobuf service definition, we can customize the generated OpenAPI schema.
We’ll start with a basic example and add options to enhance the schema.
Understanding the Speakeasy Bar Protobuf Service
Let’s explore the Speakeasy Bar protobuf service definition in proto/speakeasy/v1/speakeasy.proto
. This is the starting point for our gRPC service:
The service defines one object type called Drink
with properties like product_code
, name
, description
, and price
. It also defines a service called SpeakeasyService
that has two methods:
GetDrink
: Retrieves a single drink by its product codeListDrinks
: Lists all available drinks
Adding API Information to the Service
We can enhance our protobuf definition by adding information about the API to improve the generated OpenAPI schema. We’ll use the options.openapiv2_swagger
option from grpc.gateway.protoc_gen_openapiv2
:
This adds several important pieces of information to our API:
- Title, Description, and Version: Basic information about our API that appears in the
info
object of the generated OpenAPI schema:
- Server Information: We add a server to the API using the
host
key. Our conversion script will add theservers
object to the generated OpenAPI schema:
Adding Descriptions and Examples to Components
To create an SDK that offers a great developer experience, we recommend adding descriptions and examples to all fields in OpenAPI components. We’ll enhance the Drink
object type:
In this enhanced definition:
-
We add a
title
,description
, andexample
to theDrink
object type. Theexample
is a stringified JSON object. -
We use
openapiv2_field
to add options to the fields in theDrink
object type. For example, we add adescription
,pattern
,format
, andexample
to theproductCode
field:
If you use Speakeasy to create an SDK, this description and example will appear in the generated documentation and usage examples. For instance, in the TypeScript SDK’s documentation:
Note how the productCode
field is represented by our UUID example instead of a random string.
Customizing the OperationId
By default, the operationId
is the method name in the protobuf service definition. We can customize the operationId
for each method using options.openapiv2_operation
:
This appears in the generated OpenAPI schema:
Adding Descriptions and Tags to Methods
We can also add descriptions and tags to methods using options.openapiv2_operation
:
This adds tags and descriptions to the operation in the OpenAPI schema:
Adding Tag Descriptions
We can add descriptions to tags in the protobuf definition by using options.openapiv2_swagger
:
This adds descriptions to tags in the OpenAPI schema:
Adding OpenAPI Extensions
gRPC Gateway allows us to add OpenAPI extensions to the schema using the extensions
field in our protobuf service definition. For example, we can add the Speakeasy retries extension called x-speakeasy-retries
, which causes the SDK to retry failed requests:
This adds the extension to the OpenAPI schema:
Create an SDK With Speakeasy
Now that we have an OpenAPI 3.0 schema, we can create an SDK with Speakeasy. Speakeasy will create documentation and usage examples based on the descriptions and examples we added.
We’ll use the speakeasy quickstart
command to create an SDK for the Speakeasy Bar gRPC service.
Run the following in the terminal:
Follow the onscreen prompts to provide the necessary configuration details for your new SDK such as the name, schema location and output path. Enter openapi/speakeasy/v1/speakeasy.openapi.json
when prompted for the OpenAPI document location and select TypeScript when prompted for which language you would like to generate.
Example Protobuf Definition and SDK Generator
The source code for our complete example is available in the gRPC Speakeasy Bar example repository.
The repository contains a TypeScript SDK and instructions on how to create more SDKs.
You can clone this repository to test how changes to the protobuf definition result in changes to the SDK.
After modifying your protobuf definition, you can run the following in the terminal to create a new SDK:
Happy generating!
Last updated on