Conversation
|
Note that there is a stale branch for a 007 RFC related to gRPC reflection in connect-es - since a PR wasn't created for that, I've taken the 007 number. |
Signed-off-by: Iain McGinniss <309153+iainmcgin@users.noreply.github.com>
iainmcgin
force-pushed
the
rfc-007-rust-implementation
branch
2 times, most recently
from
242f09f to
292e85d
Compare
|
@iainmcgin is attempting to deploy a commit to the connectrpc Team on Vercel. A member of the Team first needs to authorize it. |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
| middleware abstractions. Rather than pick a winner, the server is a | ||
| `tower::Service<http::Request, Response = http::Response>` that plugs into any | ||
| Tower-compatible framework as a fallback route. A thin Axum integration helper |
There was a problem hiding this comment.
A minimal handler interface is in the spirit of Connect - this seems to be the right compromise to me.
| Connect's unary path — plain HTTP body, error as JSON body, no envelope — | ||
| would require forking most of its codec and transport layers. A standalone | ||
| implementation is simpler and does not constrain tonic's roadmap. | ||
| - **Generate a prost-backed implementation**: feasible, but loses the |
There was a problem hiding this comment.
prost doesn't implement editions, and likely never will (maintenance-status passively-maintained means that no new features are planned), right?
Given that, prost doesn't seem like a good choice to me in the long run. But it does appear to be the most popular implementation by far right now.
An adapter crate as mentioned above might make make it easier for users to migrate step-by-step. I suppose you prefer to get a sense for whether that's really the case first?
There was a problem hiding this comment.
Yes, I suspect that either teams will jump in and would be happy to convert both the proto layer and the RPC layer for the benefits, or will wait to see whether my approach gains adoption.
| Tower-compatible framework as a fallback route. A thin Axum integration helper | ||
| and a standalone hyper server are provided as optional features. | ||
|
|
||
| ## General design |
There was a problem hiding this comment.
Have you considered adding support for interceptors?
There was a problem hiding this comment.
Yes! We will need this soon for our Anthropic-internal use cases so I suspect I'll have a first cut of this in the next release.
|
I support this. Doubly so because it has Anthropic behind it, for LTS. I'm the author of https://github.com/AThilenius/axum-connect, the first foray into Rust support for Connect RPC servers. More context |
4 participants
Proposes an official Rust implementation of Connect, backed by a working implementation at https://github.com/anthropics/connect-rust that passes the full conformance suite.
See
docs/governance/rfc/007-rust-implementation.mdfor the full proposal. Markdown preview link for convenience: link.