trpc-go: A Pluggable RPC Framework Where the Codec Is Just One Plugin

A Framework Built Around Replacement

tRPC-Go is the Go language implementation of tRPC, which is a pluggable, high-performance RPC framework, and the README states the goal in a single line: multiple services can be started within a single process, listening on multiple addresses.

That first feature is a design decision rather than a convenience. A process that hosts several services on several addresses is a different deployment shape from one service per process, and it is the shape you want when the services share a connection pool, when you want one binary to start, or when the cost of a process per service is too high.

The second feature is the one that gives the framework its name. All components are pluggable, with default implementations for various basic functionalities that can be replaced, and other components can be implemented by third parties and registered within the framework.

So the framework is a set of interfaces with batteries included defaults, and the defaults are the ones most people never need to touch. The interesting part is that replacing one does not require replacing all of them, which is what keeps a pluggable design from turning into a configuration swamp.

The Codec Interface Is the Extension Point

The protocol story is the clearest example of the design, and it is stated in one sentence: the framework supports any third-party protocol by implementing the codec interfaces for the respective protocol. It defaults to supporting the trpc and http protocols, and it can be switched at any time.

A codec is the component that turns bytes into values and back. If your service speaks something the framework does not know, you write a codec for it, register it, and point the server or the client at it. Nothing else in the stack has to change, because the transport, the routing, the filters and the observability are all defined in terms of the codec's output.

The repository layout reflects that separation, with a top level codec.go, a codec/ directory for the shipped implementations, and a separate codec_stream.go for the streaming case, which is a genuinely different problem because the framing rules differ from a request and response.

The wider ecosystem follows the same pattern. The README links to codec plugins, filter plugins and database plugins in the trpc-ecosystem organisation, plus a link to the organisation itself for more, which is the clearest signal that the intended model is a core with a community of replacements.

Every Interface Is Mockable

The third feature in the list is about testing, and it is easy to overlook: all interfaces can be mock tested using gomock and mockgen to generate mock code, facilitating testing.

That sentence is short and it is a design commitment. If every component of the framework is an interface, then a test can replace any of them, and mockgen generates the implementation for you rather than a human writing a stub. The consequence is that a unit test of your service does not need the service registry, the real transport or the real filter chain, which is the difference between a test suite that runs in milliseconds and one that needs a running cluster.

The repository shows the same idea in the directory names. There is a filter/ directory, a pool/ directory for connection pools, a precool/ directory, an overloadctrl/ directory for overload control, a healthcheck/ directory, a naming/ directory for service naming, and metrics/ and log/ for observability. Each of those is a seam where a test, or a different deployment, can put something else.

The framework also ships a command line tool, the trpc command-line tool, for generating code templates, which is what removes the last piece of manual work from adding a service.

The Package Layout Is the Architecture

Reading the top level of the repository is the fastest way to understand what the framework does, because the directory names are the component names.

On the server side there is server/, transport/ for the network layer, filter/ for the request and response chain, codec/ for serialization, config/ for configuration, errs/ for error handling, and admin/ for the administrative endpoints.

On the client side there is client/ and the same transport, filter and codec layers, which is what makes the symmetry of the design visible: a client and a server are built from the same set of interchangeable parts.

The supporting packages are the ones a service platform needs and most RPC libraries leave out. There is healthcheck/ for readiness and liveness, overloadctrl/ for shedding load, pool/ for connection pooling, precool/ for warming pools ahead of use, metrics/ and log/ for observability, and rpcz/ for the RPC debugging and statistics page.

There is also restful/ and http/ for serving HTTP and REST rather than RPC, stream/ for streaming calls, and internal/ for the pieces that are not part of the public contract. A reader deciding whether this framework fits can start with restful/ and stream/, because those two directories tell you how much of the non-RPC surface is already built.

The Dependency List and the Go Floor

The go.mod declares the module as trpc.group/trpc-go/trpc-go and requires Go 1.18, which is a noticeably old floor for a project whose newest release is from 2026.

The dependencies describe what the framework does. Compression is handled by snappy, lz4 and, indirectly, brotli and klauspost/compress, and the hashing spread across xxhash, murmur3 and the standard library suggests that request identifiers and load balancing hashes are both first class. fasthttp is the HTTP server implementation, go-playground/form handles form parsing, and r3labs/sse provides server sent events, which is what a streaming or push interface would be built on.

The concurrency story is in panjf2000/ants, the goroutine pool, and in go.uber.org/automaxprocs. zap is the logger, and the use of zap rather than the standard library logger tells you that structured logging is a first class requirement rather than an afterthought.

The protocol side is google.golang.org/protobuf and the tRPC protocol definitions in trpc.group/trpc/trpc-protocol, and the transport side includes trpc.group/trpc-go/tnet. The rest of the list is ordinary infrastructure: fsnotify for configuration watching, mapstructure and cast for turning that configuration into structures, json-iterator for a faster JSON, go-multierror for aggregating failures, and testify with go-cmp for the tests.

Versioning, the Copyright Note and the Ecosystem

The release history is short and the recent part is a single major version. The tags are v1.1.0 from 2026-07-28, v1.0.3 from 2024-05-16 and v1.0.2 from 2023-12-05, and the repository is not archived with the last push on 2026-10-10, so work is current even though the version line has moved once.

There is one note in the README that a reader should not skip, and it concerns the copyright. The copyright notice pertaining to the Tencent code in this repository was previously in the name of THL A29 Limited, that entity has now been de-registered, and previously distributed copies of the code should be treated as if the notice was in the name of Tencent.

That is a corporate housekeeping detail, and it is the kind of thing that matters when you are auditing a dependency, because the entity that held the copyright has gone and the name on the notice has changed. The licence itself is Apache 2.0, as the badge in the README says, and the badge points to the LICENSE file in the repository.

The ecosystem is the trpc-ecosystem organisation, with separate repositories for codec plugins, filter plugins and database plugins, and the documentation points to a quick start guide, a detailed documentation tree, a helloworld development guide and an examples directory for various features, with the readme documents in each directory carrying the detail.

Editorial conclusion

trpc-go fits a team that runs several services in one process, that needs to support a protocol the framework does not ship, or that wants its own service discovery, load shedding and filtering without forking the framework, since every one of those is a replaceable component. It is a poor fit for a small service with one protocol and no operational requirements, because the pluggability is paid for in configuration and in the number of concepts to learn, and it is the wrong choice if you want a framework that is obviously maintained by a single community, since the copyright and ecosystem structure point to a company-backed project with a broad surface. Before adopting it, read the quick start guide and the per-directory readmes, and check which of the trpc-ecosystem plugin sets you would otherwise have to build. The framework is Apache-2.0 licensed, the newest release is v1.1.0 from 2026-07-28, and the last push was on 2026-10-10.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. trpc-group/trpc-go on GitHub