tonic

tonic is a Rust implementation of gRPC that layers a fully async client and server on top of Tokio’s async runtime and the hyper HTTP/2 stack. It ships a tonic-build code generator that turns .proto service definitions into strongly-typed Rust client stubs and server traits, so services are called and implemented with ordinary async functions rather than hand-rolled wire encoding.

Beyond the core RPC path, tonic provides first-class TLS (rustls-backed), interceptors/middleware via tower::Service, streaming (unary, client-streaming, server-streaming, bidi-streaming) support, and companion crates for server reflection, health checking, and web/gRPC-Web interop. It is the de-facto standard gRPC library in the Rust ecosystem and underpins production systems at companies including Linkerd’s proxy control plane and many other cloud-native Rust services.

What You Get

• tonic-build: compiles .proto files into typed Rust client/server code at build time via prost
• Full HTTP/2 transport with TLS (rustls) client and server support
• All four gRPC streaming modes: unary, client-streaming, server-streaming, and bidirectional streaming
• tower::Service-based interceptors and middleware for auth, logging, and request modification
• Companion crates: tonic-health (health checking protocol), tonic-reflection (server reflection), tonic-web (gRPC-Web browser interop)
• Load balancing and channel management for gRPC clients

Common Use Cases

• Building an internal microservice mesh where Rust services call each other over typed gRPC contracts
• Exposing a Rust backend to gRPC-Web browser clients via the tonic-web companion crate
• Implementing gRPC health-check and reflection endpoints expected by service meshes and infrastructure tooling (Envoy, Linkerd, grpcurl)
• Streaming large or long-lived data feeds (telemetry, logs, real-time updates) between async Rust services

Under The Hood

Architecture - tonic’s src/ splits cleanly into client, server, codec, transport, and service modules; codegen.rs provides the glue that generated tonic-build output hooks into at compile time. Requests and responses are wrapped in tonic’s own Request<T>/Response<T> types carrying gRPC metadata (metadata/), and the transport layer builds directly on hyper/h2 for HTTP/2 framing with an optional axum-based router feature for combining gRPC and HTTP routes in one server.

Tech Stack - Rust 2024 edition, built on Tokio for the async runtime, hyper/hyper-util/h2 for HTTP/2, tower/tower-service for the middleware/interceptor model, prost for protobuf encoding (via the tonic-prost/tonic-prost-build split introduced to decouple codec choice from the core crate), and tokio-rustls for TLS with a choice of ring or aws-lc-rs crypto backends.

Code Quality - The workspace has dedicated tests/ at the root plus per-crate test suites (e.g. tonic-web/tests, tonic-reflection/tests), an interop crate implementing the official gRPC interop test suite, and a grpc-benchmark crate for performance regression tracking. Feature-gating is used extensively (gzip, zstd, tls-ring vs tls-aws-lc, router, server) to keep the dependency footprint minimal for consumers who only need a subset of functionality.

API Design - Generated code exposes idiomatic async trait methods for server implementations and typed async client methods, so calling a gRPC method looks like calling any other async Rust function; tower::Service composition means existing tower middleware (retries, timeouts, load balancing) works with tonic clients/servers with minimal glue code, though the sheer number of Cargo features can make initial configuration non-trivial for newcomers.