Consuming generated SDKs#

A generated SDK is a language-native package the BSR builds from a Buf module and a plugin: pair the connectrpc/eliza module with the bufbuild/es plugin, and the BSR publishes an npm package you install like any other dependency:

$ npm install @buf/connectrpc_eliza.bufbuild_es

Every supported language has its own package registry or install surface on the BSR, so consumers reach for go get, npm install, cargo add, mvn, pip install, FetchContent, and the rest as they normally would. This is the clean handoff between schema producers and application teams: producers publish .proto files to the BSR, and consumers depend on stable packages instead of cloning schema repos, running protoc, or checking generated code into source control.

For an end-to-end walkthrough, start with the quickstart.

Why use them#

Native package-manager install. Consumers stay in the package manager they already use; nothing on the consumer side cares that the package was generated.
No client-side generation pipeline. Application teams don’t need protoc, language plugins, checked-in stubs, or a copy of the schema repository just to call an API.
Full transitive dependencies. A generated SDK declares Buf module dependencies, plugin-to-plugin dependencies, and the runtime libraries the plugin’s output needs. One install pulls in everything required to compile against the schema.
Pre-release iteration. Every BSR label, not only the default, produces SDKs. Consumers can pin a feature label or an exact commit before the producer merges those changes to the default label.
Versioning and tooling on the BSR. Each SDK has a documentation page (with a generated API reference for Go and TypeScript), and standard update tools like Dependabot and Renovate keep clients on the latest released version.

What the SDK resolves for you#

Generated SDKs ship enough metadata that the package manager handles every Buf-related dependency without any manual tracking on the consumer side. The package manifest carries three kinds of dependencies:

Module dependencies. Each Buf module the source schema imports becomes a corresponding package dependency.
Plugin-to-plugin dependencies. Many plugins generate code that requires output from another plugin (for example, a generated gRPC client uses Protobuf message types). The SDK depends on the matching message-type SDK so it’s installed automatically.
Runtime libraries. Most plugins emit code against a runtime library hosted in the language’s main registry (npm public registry, Maven Central, PyPI, etc.). Those runtimes are pulled in as ordinary package dependencies of the SDK.

The result: installing one SDK gives you everything needed to use the schema.

Working against labels and commits#

The BSR generates SDKs for every commit, not just commits on a module’s default label. Consumers can install:

The latest commit on a module’s default label (the default if no version is specified).
The latest commit on any other label, for previewing in-flight changes.
An exact commit ID, for reproducible builds.

For exact-version pinning across plugins, see the buf registry sdk version CLI command.