We have a lot of plans to work towards our goal of making Protobuf easier to use than JSON. While outside of the Buf CLI v1.0, none of the below is guaranteed, this document serves as a very rough overview of our intentions.
Buf CLI v1.0
Right now, Buf is just a CLI tool that contains linting and breaking change
detector, and we're in beta. During the beta, we'll take customer feedback and refine what
we have, as well as add a
STRICT lint category. We may also release an internal GitHub App
we've developed that runs Buf and annotates files on GitHub PRs, although that is unlikely
(we recommend Reviewdog for this purpose).
Regardless, we aim to make the Buf CLI hit a stable v1.0 by the end of the year or soon thereafter.
The Buf CLI tool and the features it contains, including all existing functionality, will always remain free and open source. We hope that linting and breaking change functionality, along with other CLI functionality that intend to add such as inspection, is a win for your organization or personal projects, and please help us make it even better.
Buf Schema Registry
Next up is the Buf Schema Registry, a publicly hosted and on-prem service.
The Buf Schema Registry will receive Images built by
buf, and let you produce
and consume various generated artifacts such as:
- Language-specific stubs, for every version of
protocand associated language plugins. The stubs will initially be consumable via direct download, but the goal is to allow you to use language-specific tools - for example, with Golang, we'll have a module proxy server.
- Hosted documentation for your Protobuf APIs - given an Image, we can generate version-specific documentation.
- Generated CLIs - have a versioned service-specific CLI for every service you own, downloadable on demand.
- Tarballs that contain your
.protofiles alongside Bazel build rules, to allow easy consumption for Bazel repositories - there's no need for you to have us invoke your plugins if you are using Bazel, but we can still manage the process of rule creation for you. Additionally, having hosted Images still allows many use cases, including the ability to host subsets of your Protobuf APIs for external consumers.
The goals are wide-ranging, including:
- Consume your artifacts for every version of the plugins you care about. If you
want Java stubs for
protoc v3.10.0, you get stubs specifically for this version. If you want
protoc-gen-grpc-gateway v1.11.3, you'll get stubs for these versions, along with an associated
go.modfile at the root.
- Automatic and deterministic (but optional) setting of language-specific file options,
go_package. Setting some of these options is important for modern Protobuf development, but having to set them in each of your files leads to extra work and inconsistencies. See our discussion for more details.
- Cross-image dependency support - import Protobuf definitions from other Images automatically, with version pinning.
Depending on need and demand, we may not implement all of the above - the types of generated artifacts and goals should serve as a reference point for our goals with this project. What we concentrate on first within these large goals will largely be determined by our initial customers. If you're interested in learning more, contact us.
Our intention is to make OSS projects free, while private projects and on-prem will be a paid service. Developer time is expensive - we want to provide you with the best products we can, and we feel that running this as an independent company is the best way to do so.
Once we have The Buf CLI tool and Buf Schema Registry, the possibilities of what we can build next are extensive, including:
- Mock server generation - given a Protobuf schema, produce mock servers that return dummy data automatically for every Service.
- Fuzz testing - slam your servers with fuzzed data for every Service.
- google.protobuf.Any type URL server, including versioning.
We have some specific goals beyond these, and are happy to discuss them with you if you'd like to get involved. There's a long way to go between where we are today in the Protobuf ecosystem, and a setup where Protobuf is considered easier to use than JSON, but we hope to get there in the future with your support.