--- title: gRPC-Rust Client API Evolution (pt. 2/2) | daily.dev description: Details the design process behind the gRPC-Rust client channel API, the low-level trait-based interface that generated code and interceptors use under the... canonical: https://daily.dev/posts/grpc-rust-client-api-evolution-pt-2-2--usaglym3o twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: gRPC-Rust Client API Evolution (pt. 2/2) | daily.dev og:description: Details the design process behind the gRPC-Rust client channel API, the low-level trait-based interface that generated code and interceptors use under the... og:url: https://daily.dev/posts/grpc-rust-client-api-evolution-pt-2-2--usaglym3o og:image: https://api.daily.dev/og/posts/usAglyM3o.png og:image:alt: gRPC-Rust Client API Evolution (pt. 2/2) og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # gRPC-Rust Client API Evolution (pt. 2/2) **[gRPC Blog](https://daily.dev/sources/grpc-blog)** · 7 min read · 0 upvotes · 0 comments ## Summary Details the design process behind the gRPC-Rust client channel API, the low-level trait-based interface that generated code and interceptors use under the hood. Covers decisions around avoiding generics in favor of dynamic type references for messages, why a split send/receive stream design was chosen over a single Stream object, the switch from RPITIT to associated types to solve lifetime and naming problems for retry support, and the resulting four distinct interceptor variants (Basic, Once, Retryable, RetryableOnce) needed to handle Rust's ownership model with one-shot channels. Concludes that this design has shipped as a preview release, open to feedback. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Why did the gRPC-Rust team choose associated types instead of RPITIT for the Invoke trait's stream return types? Associated types let the returned stream types be named, so they can be stored in structs with named type parameters and updated on retry attempts. RPITIT (return position impl trait in trait) produces anonymous types, making it impossible to store two instances from the same delegate in the same wrapper, and RPIT streams implicitly capture the lifetime of the &self receiver instead of being 'static. _Rust developers designing generic streaming APIs can track these interceptor and trait patterns on daily.dev._ ### Why does gRPC-Rust use dynamic type references for messages instead of generics like Tower and Tonic? Dynamic type references avoid the compile-time and code-size costs of plumbing generics through the whole stack, while still avoiding heap allocations by passing references to dynamic message types (e.g. fn next_response_message(dest: &mut dyn ResponseMessage)) rather than owned, boxed objects. Static type safety was judged unnecessary since the application-facing API is already fully type-safe. _Comparing generic versus dynamic dispatch trade-offs in Rust RPC libraries is easier with daily.dev's developer content._ ### Why does gRPC-Rust need four different kinds of interceptors instead of one generic interceptor trait? Rust's strict ownership model requires distinguishing one-time-use interceptors (like a metadata accessor backed by a Tokio oneshot channel) from reusable ones, and single-delegate-use from multi-use (retryable) ones. This yields four variants: Basic (reusable, one-time delegate use), Once (non-reusable), Retryable (reusable, multiple delegate use), and RetryableOnce (non-reusable, multiple delegate use), implemented via Intercept and InterceptOnce traits. _Developers building interceptor chains in Rust can follow evolving API patterns like this on daily.dev._ ## Similar posts on daily.dev - [gRPC-Rust Roadmap](https://daily.dev/posts/grpc-rust-roadmap-jhgiaf4vu) · gRPC Blog · 69 upvotes · 6 comments - [Practical Rust API Design](https://daily.dev/posts/practical-rust-api-design-qwmqrnfyi) · corrode · 49 upvotes · 7 comments - [From RPC to gRPC: Understanding Remote Procedure Calls, Protocol Buffers, and Modern Distributed Systems Communication](https://daily.dev/posts/from-rpc-to-grpc-understanding-remote-procedure-calls-protocol-buffers-and-modern-distributed-sys-hdfydjpc0) · freeCodeCamp · 1 upvotes · 0 comments - [Concurrent Servers: Part 7](https://daily.dev/posts/concurrent-servers-part-7-p5cowxjcu) · Eli Bendersky · 4 upvotes · 0 comments --- Tags: [#architecture](https://daily.dev/tags/architecture), [#rust](https://daily.dev/tags/rust), [#grpc](https://daily.dev/tags/grpc) [View this post on daily.dev](https://daily.dev/posts/grpc-rust-client-api-evolution-pt-2-2--usaglym3o) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"gRPC-Rust Client API Evolution (pt. 2/2)","url":"https://daily.dev/posts/grpc-rust-client-api-evolution-pt-2-2--usaglym3o","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/grpc-rust-client-api-evolution-pt-2-2--usaglym3o"},"datePublished":"2026-08-23T07:20:18.297Z","dateModified":"2026-08-23T07:22:27.317Z","description":"Details the design process behind the gRPC-Rust client channel API, the low-level trait-based interface that generated code and interceptors use under the...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/10aae04dfd3ba4523d83e4087201877a?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/10aae04dfd3ba4523d83e4087201877a?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"gRPC Blog","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"gRPC Blog","logo":"https://media.daily.dev/image/upload/s--asedGCAx--/f_auto,q_auto/v1787469607/logos/grpc-blog?_a=BAMAMicg0","url":"https://daily.dev/sources/grpc-blog"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/grpc-rust-client-api-evolution-pt-2-2--usaglym3o","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"architecture,rust,grpc","timeRequired":"PT7M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"gRPC Blog","item":"https://daily.dev/sources/grpc-blog"},{"@type":"ListItem","position":3,"name":"gRPC-Rust Client API Evolution (pt. 2/2)"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/grpc-rust-client-api-evolution-pt-2-2--usaglym3o#faq","mainEntity":[{"@type":"Question","name":"Why did the gRPC-Rust team choose associated types instead of RPITIT for the Invoke trait's stream return types?","acceptedAnswer":{"@type":"Answer","text":"Associated types let the returned stream types be named, so they can be stored in structs with named type parameters and updated on retry attempts. RPITIT (return position impl trait in trait) produces anonymous types, making it impossible to store two instances from the same delegate in the same wrapper, and RPIT streams implicitly capture the lifetime of the &self receiver instead of being 'static. Rust developers designing generic streaming APIs can track these interceptor and trait patterns on daily.dev."}},{"@type":"Question","name":"Why does gRPC-Rust use dynamic type references for messages instead of generics like Tower and Tonic?","acceptedAnswer":{"@type":"Answer","text":"Dynamic type references avoid the compile-time and code-size costs of plumbing generics through the whole stack, while still avoiding heap allocations by passing references to dynamic message types (e.g. fn next_response_message(dest: &mut dyn ResponseMessage)) rather than owned, boxed objects. Static type safety was judged unnecessary since the application-facing API is already fully type-safe. Comparing generic versus dynamic dispatch trade-offs in Rust RPC libraries is easier with daily.dev's developer content."}},{"@type":"Question","name":"Why does gRPC-Rust need four different kinds of interceptors instead of one generic interceptor trait?","acceptedAnswer":{"@type":"Answer","text":"Rust's strict ownership model requires distinguishing one-time-use interceptors (like a metadata accessor backed by a Tokio oneshot channel) from reusable ones, and single-delegate-use from multi-use (retryable) ones. This yields four variants: Basic (reusable, one-time delegate use), Once (non-reusable), Retryable (reusable, multiple delegate use), and RetryableOnce (non-reusable, multiple delegate use), implemented via Intercept and InterceptOnce traits. Developers building interceptor chains in Rust can follow evolving API patterns like this on daily.dev."}}]} ```