Skip to main content

16 Bonus — Use Remote Generation

The Remote Generation feature is experimental.

In this section, we'll learn how to use Buf's Go Module Proxy to import the Go/gRPC client and server stubs like any other ordinary library.

This simplifies the code generation workflow to be as simple as buf push followed by go get or go mod tidy.

16.1 Remove buf.gen.yaml#

We won't need to generate anything locally anymore, so we can remove the buf.gen.yaml, as well as the generated code found in the gen/ directory:

$ rm buf.gen.yaml$ rm -rf gen

As expected, if you try to compile your Go program again, you'll notice a compilation error:

$ go build ./...client/main.go:10:2: no required module provides package; to add it:    go get

16.2 Depend on

We can depend on the same Go/gRPC client and server stubs by adapting our import paths to use, which is one of the BSR's hosted templates.

In short, the go-grpc template acts exactly like the local buf.gen.yaml template we just removed, (i.e. it executes the protoc-gen-go and protoc-gen-go-grpc plugins).

The Go module path we need to use is derived from the name of the module we want to generate for, as well as the name of the template we want to generate with:

With module$BUF_USER/petapis and template, the result becomes:$BUF_USER/petapis

Update your import paths like so:

 package main
 import (     "context"     "fmt"     "log"
-    // This import path is based on the name declaration in the go.mod,-    // and the gen/proto/go output location in the buf.gen.yaml.-    petv1 ""+    petv1 "$BUF_USER/petapis/pet/v1"     "" )
 package main
 import (     "context"     "fmt"     "log"     "net"
-    // This import path is based on the name declaration in the go.mod,-    // and the gen/proto/go output location in the buf.gen.yaml.-    petv1 ""+    petv1 "$BUF_USER/petapis/pet/v1"     "" )

Now if you run the following command, you'll notice that the remote-generated library is resolved:

$ go mod tidygo: finding module for package$BUF_USER/petapis/pet/v1go: found$BUF_USER/petapis/pet/v1 in$BUF_USER/petapis v1.4.4go: downloading$BUF_USER/paymentapis v1.4.1

With this, the Go/gRPC client and server stubs are included in your go.mod just like any other ordinary Go library.

16.3 Run the Application#

We can run the application again to verify the remote-generated library works as expected.

Run the server with the following:

$ go run server/main.go... Listening on

In a separate terminal, run the client and you'll notice the following:

$ go run client/main.go... Connected to Successfully PutPet

You'll also notice the following in the server logs (in the other terminal running the server):

$ go run server/main.go... Listening on Got a request to create a PET_TYPE_SNAKE named Ekans

Everything works just as before, but we don't have any locally generated code:

start/├──├── client│   └── main.go├── go.mod├── go.sum├── paymentapis│   ├── buf.lock│   ├── buf.yaml│   └── payment│       └── v1alpha1│           └── payment.proto├── petapis│   ├── buf.lock│   ├──│   ├── buf.yaml│   └── pet│       └── v1│           └── pet.proto└── server    └── main.go

16.4 Synthetic Versions#

Now that we're depending on the remote-generated library, it's important to discuss how it is versioned.

The challenge with versioning remote generated code, is that it is the product of two logical inputs: the Protobuf module and the template version. The lowest common denominator of the language registry ecosystems we surveyed is "semantic versioning without builds or pre-releases", so something like v1.2.3.

To ensure that we can create consistent, and lossless synthetic versions, we simplify the versioning schemes of the two inputs. Both template versions, and Protobuf module versions, are represented as monotonically increasing integers.

  • For hosted Templates we enforce a version of the form v1, v2, vN....
  • For Protobuf modules we use the commit sequence ID. This ID is an integer that uniquely idenfities a commit. It is calculated by counting the number of commits since the first commit of a module (i.e. the first commit has a sequence ID of 1, the second commit has a sequence ID of 2, and so on).

With these simplified versioning schemes we create a synthetic version which takes the following form:


As an example, the version v1.3.5 represents the 3rd version of a hosted template and the 5th commit of a Protobuf module.

In this case, we're using the 4th version for both the hosted template and the Protobuf module:

go 1.16
require ($BUF_USER/petapis v1.4.4 v0.0.0-20210811021853-ddbe55d93216 // indirect v1.40.0)

16.5 Updating Versions#

When you update your module and push new commits, you can update your library version by incrementing the final element in the synthetic version (described above).

To demonstrate, make a simple change by adding a simple comment to the PetStoreService:

$ cd petapis
+// PetStoreService defines a pet store service. service PetStoreService {   rpc GetPet(GetPetRequest) returns (GetPetResponse) {}   rpc PutPet(PutPetRequest) returns (PutPetResponse) {}   rpc DeletePet(DeletePetRequest) returns (DeletePetResponse) {}   rpc PurchasePet(PurchasePetRequest) returns (PurchasePetResponse) {} }

Push the latest changes with the following command:

$ buf push8535a2784a3a48f6b72f2cb80eb49ac7

Now, edit your go.mod to use the latest version (i.e. the 5th commit):

 go 1.16
 require (-$BUF_USER/petapis v1.4.4+$BUF_USER/petapis v1.4.5 v0.0.0-20210811021853-ddbe55d93216 // indirect v1.40.0 )

If you run the following command, you'll notice that your go.sum is updated with the version specified in your go.mod:

$ go mod tidy
go.sum$BUF_USER/petapis v1.4.4$BUF_USER/petapis v1.4.4/go.mod$BUF_USER/petapis v1.4.5 h1:kW63uI3YuRvHb4WPrn7dJQLUaMHuNE3x/$BUF_USER/petapis v1.4.5/go.mod h1:aKE843ItBFu7UPuaxuUJvNpqC2hjVagPYiJ20n9dBJQ=