A drop-in, lightweight gRPC replacement.

• DRPC website
• Examples
• Quickstart documentation
• Launch blog post

• Simple, at just a few thousand lines of code.
• Small dependencies. Only 3 requirements in go.mod, and 9 lines of go mod graph!
• Compatible. Works for many gRPC use-cases as-is!
• Fast. DRPC has a lightning quick wire format.
• Extensible. DRPC is transport agnostic, supports middleware, and is designed around interfaces.
• Battle Tested. Already used in production for years across tens of thousands of servers.

• go.bryk.io/pkg/net/drpc

  • Simplified TLS setup (for client and server)
  • Server middleware, including basic components for logging, token-based auth, rate limit, panic recovery, etc
  • Client middleware, including basic components for logging, custom metadata, panic recovery, etc
  • Bi-directional streaming support over upgraded HTTP(S) connections using WebSockets
  • Concurrent RPCs via connection pool

• go.elara.ws/drpc

  • Concurrent RPCs based on yamux
  • Simple drop-in replacements for drpcserver and drpcconn

• Open an issue or join the Zulip chat if you'd like to be featured here.

• A basic drpc client and server
• A basic drpc client and server that also serves a Twirp/grpc-web compatible http server on the same port
• Serving gRPC and DRPC on the same port

DRPC can be made compatible with RPC clients generated from other languages. For example, Twirp clients and grpc-web clients can be used against the drpchttp package.

Native implementations can have some advantages, and so some support for other languages are in progress, all in various states of completeness. Join the Zulip chat if you want more information or to help out with any!

DRPC is licensed under the MIT/expat license. See the LICENSE file for more.

These microbenchmarks attempt to provide a comparison and come with some caveats. First, it does not send data over a network connection which is expected to be the bottleneck almost all of the time. Second, no attempt was made to do the benchmarks in a controlled environment (CPU scaling disabled, noiseless, etc.). Third, no tuning was done to ensure they're both performing optimally, so there is an inherent advantage for DRPC because the author is familiar with how it works.

DRPC is proud to get as much done in as few lines of code as possible. It's the author's belief that this is only possible by having a clean, strong architecture and that it reduces the chances for bugs to exist (most studies show a linear corellation with number of bugs and lines of code). This table helps keep the library honest, and it would be nice if more libraries considered this.