Rust implementation

[akshayjshah]

Would you or your company use a Connect implementation in Rust? If yes, please leave a comment and tell us more about what you'd like (especially if you need integration with a particular framework).

[washanhanzi]

Not a rust expert, just want to share some thoughts.
I think it's reasonable to use hyper and tokio, maybe with tower? or make the implementation compatible with tower.
And also I think this is a doable approach to make a first step into rust with connect protocol, and then let the project evolve with the rust ecosystem.
With pluggable async runtime? I think it will add a lot of workload.

[frederikhors]

Do you kind people know https://github.com/AThilenius/axum-connect?

[akshayjshah]

We sure do! We haven't talked to Alec in a while, but we did chat a bit when he first started working on this project. If we end up investing in a Rust implementation, the first thing we'll do is see if Alec wants to move his package over to the connectrpc organization :)

In general, we're reluctant to get too far into Rust until the state of protobuf serialization improves. prost doesn't pass the protobuf conformance tests, but there are some signs of progress: the technical lead of Google's protobuf team is now one of the maintainers of the protobuf crate and there's Rust landing in the protoc repository.

[AThilenius]

Ah, shame Github never sent me a notification about this!

I can TL;DR the pros and cons of both axum-connect and more generally protobuf in Rust (with the disclaimer that this is one engineers opinion, and so on).

The awesome:

Axum Connect is stable, and has been used by both me and a good number of other people now. It implements both unary and streaming RPCs. Connect is web-first, so the benefits of seamless integration into existing Axum web servers cannot be overstated. From what I can tell, Axum Connect is unique in this way, most other Rust RPC frameworks (proto or otherwise) are standalone APIs and to my knowledge no other server framework speaks Connect's protocol.

Axum is very important, so important that I chose to put Axum in the name of the thing. Axum allows you to, with very little verbosity, bake business assumptions into the types (not metadata, the actual type definitions themselves) of handlers. A good example of this is auth, if you wrap user info in a type that requires auth to construct, then you have just made it impossible to accidentally forget auth in a handler. It's the best use of RAII I've ever come across, and mind-blowing that Rust allows you to express all of it in normal types without any extra metadata. For a production web server, having the compiler cover business logic has been such a wonderful breath of fresh air for my team (I generally find the web ecosystem to be an absolute dumpster-fire lol)

The less-than-awesome:

TL;DR: Protocol buffers in Rust

The warts of axum-connect are all related to protocol buffers in Rust. It's a rough, fragmented space with a lot of really... strange... decisions. I started with Prost like everyone, but it's a painfully obtuse and overly-complicated design. I then tried https://github.com/stepancheg/rust-protobuf which was much more elegant but had a limitation that I cannot remember now, and I had to go back to Prost. In that time I learned that rust-protobuf existed first, but the Prost team created Prost without ever contacting him to collaborate. Additionally, the Prost team has made some real weird decisions like no longer shipping protoc for "security", which makes absolutely no sense to me. The code generator was very challenging to hook, and Prost has no JSON support so I had to pull in another dep for that.

The ugliest part of axum-connect is the protobuf support, and trying to get it working with JSON. It was a nightmare and required a lot of pouring through Prost source. The impl is fragile and involves a lot of nasty string-replace hacks. My ideal would for the Rust community to build a new lean-and-mean, 100%-rust, proto3-only implantation. That could be done in a few hundred lines of PEG, and the code generator isn't that complicated. Something highly opinionated but easily hookable for code-gen and RPC dispatch. Then you could either include_proto!("path/to/file.proto") right in your rust code and forget all about codegen, or invoke it as a plugin with Buf. I have the expertise to build such a thing (I also built https://gitlab.com/tungstenlabs/maglev which implements it's own protobuf code generator as well), but very much not the time.

So @akshayjshah is correct in being weary of protobuf in Rust. Perhaps I'm overly negative, but dealing with Prost left some scars 😂 But... Rust is an incredible language. The safety you get from things like Axum (that extend into axum-connect) are industry-leading. I highly support Connect officially supporting Rust.

---

Unrelated, I know the author of https://github.com/lann/connect-rpc-rs personally. He was my tech lead back at Google and the co-founder of Maglev along with me. I don't think he has interest in maintaining that project, but I'm sure would help hand it off.

[frederikhors]

I saw the news about Buf Rust SDK, is Rust backend coming?

[akshayjshah]

Not necessarily - they're separate projects :) Appreciate the enthusiasm, though!

[kanpov]

Additionally, axum-connect hasn't received a single update in 7 months so it doesn't seem like a viable solution.

[frederikhors]

It's active! No update doesn't mean is abandoned.

[AThilenius]

It's active 😁 It's very stable and implements almost everything I want it to.

[pret-a-porter]

There is another implementation https://github.com/lann/connect-rpc-rs

[frederikhors]

It looks pretty abandoned.

[conradwt]

@pret-a-porter @frederikhors Has anyone run this implementation against the connectconformance binary for this implementation to determine what's working and not-working?

[yordis]

Hey @akshayjshah I wonder if you could share some update about the discussion.

[junsazanami430u]

@akshayjshah
https://groups.google.com/g/grpc-io/c/ExbWWLaGHjI/m/TJssglLiBgAJ

What are your thoughts on this grpc-io official move to support rust?

[conradwt]

@junsazanami430u Yes, this is great move by Google gRPC team and the creator of Tonic, Lucio Franco of Turso, which was announced at gRPC Summit 2024. Thus, I'm really looking forward to gRPC Conference 2025.

[frederikhors]

Any news about grpc-rust? Something we can try?

[yaroher]

Hello everyone. I introduce my axum-connect plugin for protoc. Let's check out here https://github.com/yaroher/protoc-gen-axum-connect. Welcome to report issues and and give stars)

[AThilenius]

Very nice!

[FedorKiselev76]

I have tested connectrpc-axum, confirmed support for pure Connect (proto), and successfully migrated an existing Go Connect service to it

[washanhanzi]

oh, this one? https://github.com/washanhanzi/connectrpc-axum
I(Claude) am currently refactor the repo.

[FedorKiselev76]

Yes — it’s this exact repo: washanhanzi/connectrpc-axum

I use it in a very straightforward setup.

I have one Axum server and one port**, and on that same port I run:

• Connect (proto) for browser and Flutter clients
• Regular gRPC for internal services
• An HTTP admin UI

In the latest versions, auto-detection was fixed and improved, and that made things much nicer.
Now it automatically detects whether a request is:

• Connect
• gRPC
• plain HTTP

and routes it correctly without any manual setup. At this point it’s basically plug-and-play.

My setup is roughly:

• generate service builders with connectrpc-axum-build
• build a connect_router
• add gRPC services via add_grpc_service(...)
• merge everything with MakeServiceBuilder
• apply a single CORS layer (important for browsers)

End result:

• one binary
• one port
• everything just works
• Connect, gRPC, and HTTP live together naturally

It finally feels like RPC is a first-class citizen inside Axum, not something bolted on from the side. Huge thanks to @washanhanzi for the great work on this project!

[washanhanzi]

I didn't post the repo here earlier because it is still in early stages: connectrpc-axum.

In the Rust ecosystem, web frameworks generally follow two styles:

Axum-style, based on the implementation, we got:

• Type Erasure: axum. Strong compile-time type safety. The trade-off is the complexity of "type hell."
• Code Generation: Salvo.

Go-idiomatic style: tonic

I chose the Axum api style and similar implementation for this crate. This allows you to leverage the full Axum ecosystem, enabling a gradual migration from a standard Axum HTTP app to a hybrid HTTP and Connect app. Compare to axum-connect, my goal was to maintain native compatibility with the existing Axum ecosystem.

In order to support Tonic with Axum handler, I added a restriction that Tonic-compatible handlers only allow (ConnectRequest) or (State<S>, ConnectRequest) as arguments.
Also you can use the same axum handler for tonic server.

The repo currently relies on prost, axum, and tonic. As a next step, maybe moving to the official protoc rust generator.

[Davincible]

For anyone else curious about how https://github.com/washanhanzi/connectrpc-axum stacks up against https://github.com/AThilenius/axum-connect, I let Opus wild on a review run, this is what it came up with

---

Deep Comparison: connectrpc-axum vs axum-connect
Quick Overview

Aspect	connectrpc-axum	axum-connect
Rust Code Lines	~12,000	~1,400
Version	Pre-1.0 (active dev)	0.5.3
Test Coverage	Extensive (~40% is tests)	None
Maturity	More complete	Minimal viable

---

Feature Comparison

Feature	connectrpc-axum	axum-connect
Unary RPC	Yes	Yes
Server Streaming	Yes	Yes
Client Streaming	Yes	No
Bidi Streaming	Yes	No
JSON Encoding	Yes	Yes
Protobuf Encoding	Yes	Yes
GET Requests	Yes	Yes
gRPC Support	Yes (via Tonic)	No
gRPC-Web Support	Yes (via tonic-web)	No
Compression (Streaming)	gzip, deflate, br, zstd	No
Timeouts	Yes (Connect-Timeout-Ms)	No (TODO)
Message Size Limits	Yes	No
Error Details	Yes (google.rpc.*)	Partial
Trailers/Metadata	Yes	No (intentionally)

---

Why the 10x Size Difference?
The ~10x code difference comes from:

1. Full Streaming Support - connectrpc-axum implements all 4 RPC types; axum-connect only does unary + server streaming
2. Tonic/gRPC Integration - connectrpc-axum lets a single handler serve Connect, gRPC, AND gRPC-Web simultaneously
3. Compression - connectrpc-axum has 4 compression algorithms with per-envelope and HTTP-level compression
4. Test Coverage - ~40% of connectrpc-axum is tests (~500+ lines in error.rs alone), while axum-connect has zero tests
5. Production Features - Timeouts, size limits, protocol version validation, detailed error handling

---

Code Quality Comparison
connectrpc-axum:

// Extensive error handling with fallback responses
pub(crate) fn internal_error_response(content_type: &'static str) -> Response
pub(crate) fn internal_error_end_stream_frame() -> Vec<u8>
// Full protocol detection
pub enum RequestProtocol {
    ConnectUnaryJson,
    ConnectUnaryProto,
    ConnectStreamJson,
    ConnectStreamProto,
    Unknown,
}

// Middleware layer stack with proper Tower integration
BridgeLayer -> CompressionLayer -> ConnectLayer -> Handler

axum-connect:

// Clean but minimal - many TODOs
// From handler_unary.rs:28-33
// TODO: protocol version validation
// TODO: timeout handling  
// TODO: metadata parsing
// From lib.rs - acknowledged hack
// TODO: This is a nasty hack. Get rid of it.
let files = Rc::new(RefCell::new(vec![]));

---

API Ergonomics
Both have good Axum-style APIs, but axum-connect is slightly cleaner due to its simplicity:

axum-connect:

let app = Router::new()
    .rpc(HelloWorldService::say_hello(say_hello_handler))
    .rpc(HelloWorldService::say_hello_stream(stream_handler));

connectrpc-axum:

let router = HelloWorldServiceBuilder::new()
    .say_hello(say_hello)
    .build_connect();  // or .build_tonic() for gRPC support

---

My Assessment

Criteria	Winner	Notes
Production Readiness	connectrpc-axum	Tests, compression, timeouts, error handling
Feature Completeness	connectrpc-axum	All RPC types, gRPC, full protocol
API Simplicity	axum-connect	Cleaner, more Axum-like
Code Quality	connectrpc-axum	Tests, documentation, edge cases
Learning/Prototyping	axum-connect	Simpler to understand
gRPC Interop	connectrpc-axum	Tonic integration

---

Recommendation
Use connectrpc-axum if you need:

• Client streaming or bidirectional streaming
• gRPC or gRPC-Web compatibility
• Production deployment with compression, timeouts, size limits
• Confidence from test coverage
  Use axum-connect if you need:
• Just unary + server streaming
• Minimal dependencies (no Tonic)
• Simpler codebase to fork/modify
• Quick prototyping

[washanhanzi]

Thanks for the comparison. Also, big thanks to Alec for his work on axum-connect.

connectrpc-axum started as a fork of axum-connect to experiment with different API boundaries and tighter integration with Axum. Over time — with real internal production usage and community help (especially thanks to @FedorKiselev76 ) — it grew into a more feature-complete implementation.

Today it can serve Connect, gRPC, gRPC-Web, and plain HTTP from a single Axum handler with full extractors support. I think this provides a smooth developer experience.

I'm currently preparing for a 0.1.0 release.

If anyone tries it and hits issues, has suggestions, or wants features, please open an issue. I have a Claude skill for submitting issue

On the AI part: The repo was initially built during the Claude-4-sonnet era (with a mix of hand-written and assisted code), but as models improved dramatically (Claude-4.5-opus, GPT-5.2-codex, Gemini-3-pro), nearly 100% of new code and refactors are now AI-generated — with me reviewing, steering, testing, and iterating heavily. My view is simple: let the code speak, it need to be clean, well-structured, maintainable, follows solid patterns, and solves the problem correctly. If it does, I don't care what tool produced the lines — copy-paste from Stack Overflow, or LLM.

Happy to discuss any specific technical details (e.g. Tonic interop, streaming handling) or AI usage.

[Davincible]

@AThilenius I feel you, the OG contribution. Sounds great, thank you for your hard work. Agree that two libs is a bit of a fragmentation (and why I was curious to compare). Ideally we would have a single, high quality library that covers it all.

From what I am understanding, your lib is the OG, but lacks some of the other features @washanhanzi has covered.

On the topic of AI here, in my personal experience AI usage is not black and white, can be good or bad just like a human engineer. It does provide a lot of power since you can cover much more ground easily. With that, a properly architected library where the human engineering drives the design, and an AI is used to execute and iteratively review that works quite well in my experience. Opus especially is really powerful.

If you ask me I'd vouch for a single cohesive lib, that works ergonomically following ideomatic Rust, leveraging AI to cover the full spectrum in a high quality manner.

[FedorKiselev76]

Thanks everyone for the thoughtful and constructive discussion.
I’m gradually coming to see Rust as a language well suited for expressing ideas and invariants, not just writing code.
Because of its strictness, Rust is also an ideal environment for building with AI: the same problem can be implemented in many different ways, then compared and refined to find a better solution.
The value of the code itself is often secondary — what matters more is clarity of intent and constraints.
This makes Rust a great fit for both business problems and engineering creativity, reducing reliance on commercial or third-party products and enabling more to be built independently, with a clear idea and a cup of coffee.

[washanhanzi]

After stripping away all the added features, the core difference lies in the Handler part, which I described here.
I also refined the architecture document.

[AThilenius]

I'm sorry, but your understanding of how your own library works is largely wrong. Your handler generator extracts the body right here, which impls the from request here, calling through to here which deserilizes the protobuf right here. This is all exactly how axum-connect works, with way more unnecessary layers of abstraction.

Your generated code right here call through to here and the builder merges those routers. That's just a super convoluted way of registering a route on the Axum router like axum-connect does right here.

All axum-connect handlers are also "HTTP handlers" because that's the whole point of Connect's web-first protocol. There is no "tighter integration with Axum" as the both work the exact same way once you strip back all the abstractions.

I respectfully disagree that your library is in any way fundamentally different, and I politely (as polite as is possible I guess) reassert that you're misrepresenting the "differences" between our libraries only because you do not understand how your own library works. There are so many layers of abstraction it's difficult for even me to trace. But net-net it is nearly identical, with a lot more abstraction and doesn't enforce semantically correct handlers. It also adds Tonic support, which would be lovely to have in axum-connect no doubt.

[washanhanzi]

connectrpc-axum has been updated to 0.1.0-beta.5. This release features a full refactored test suite and a client implementation! I've also shared a blog post on the project's background and technical design—hopefully, it's a useful resource for anyone working on their own ConnectRPC implementation.

[sagsfaller0e]

Came across this by Anthropic: https://github.com/anthropics/connect-rust. I haven’t tried it yet, but based on the docs, it looks promising.

[iainmcgin]

Hi folks, as @sagsfaller0e points out we released a fully conformant protobuf and ConnectRPC implementation last week:

• buffa is a from-scratch pure Rust implementation of protobuf with editions support (meaning it supports proto2, proto3, 2023, and 2024 via feature selection). It has built-in JSON encode/decode support with serde, and I'm about to push textproto support for completeness. Leaning into Rust's capabilities, it also has zero-copy views, allowing string/byte data in messages to be shared from input buffers, which can help significantly for RPC performance with string-heavy messages.

• connect-rust is a full implementation of ConnectRPC, including gRPC and gRPC-Web support, for both clients and servers. It is Tower based, has some Axum helpers, and ships with its own "standalone" hyper-based server if you don't need a specific web framework.

An RFC is up to consider promoting this to the official ConnectRPC implementation for Rust.

Performance is very competitive with tonic, prost, and Google's beta upb-wrapping protobuf implementation. It's a 0.x release for the time being while I work out some ergonomics kinks and do further profiling-guided performance optimizations. I'll be publishing a road map for additional features in the next week or so. We're already using this implementation in production at Anthropic - I hope y'all are willing to give it a shot, and open issues for anything you find, no matter how small!

[AThilenius]

I throw my support behind this and second the proposal for acceptance as the official ConnectRPC Rust impl.

Buffa is huge, and desperately needed. And mind-boggling that you threw it together in what looks like less than 2 weeks with Claude. Protobuf support was the hamstring that made axum-connect so painful to write (by hand, like a caveman).

My experience with Claude Code is that it thrives on type checks; the more application logic I've been able to bake into the type system itself, the better I find Claude's results. So I'm not entirely convinced that the value of direct integration with Axum's extractors pattern (a very elegant "baking application logic into type signatures" solution) isn't still the right abstraction in a world of Claude Code. But software is also being turned upside down right now, and in a world of ever-more amorphous software and greenfield codebases, this may very well be the better abstraction layer. I also don't have the time to give axum-connect the full Claude Code makeover it needs.

Bravo @iainmcgin, and thank you Anthropic for the contribution. Now if you'll excuse me, I need to go have another existential crisis about the future of society in a world where Claude exists.

[iainmcgin]

Trust me, we're all anxious about the existence of Claude here too 😆 This project was an experiment for me in seeing how far Opus 4.6 could run when guided by good specifications and conformance tests. It turns out, very far, but it's still not fully autonomous - I still had some value to contribute in steering ergonomics and asking "but why did you do it that way" questions. There's still more to be done, but I think it's in a good spot for people to try out and provide feedback to improve it further and faster.

[AThilenius]

Yep! And Rust's type system forces a clear ownership model and provides lesser 'acceptance tests' in it's type system. Those rare cases where I can full define success criteria, where unit tests and integration tests can drive a lot of the implementation, I've been blown away by what Claude Code can do. When the idea is poorly formed in my head, or the system is truly novel, I sometimes finding myself using Claude as a computationally expensive rubber duck.

It'll be really exciting to see what becomes of software in a world where implementation is this cheap. I see end-users regularly JITing code to augment systems in the near future, and later on perhaps entire systems built around the core concept of 'just make the UI/UX you personally want' instead of pre-canned systems. That's a WILD thought process to go down. Protobuf (well-structured IDL with high-performance protocols) play a part there, and I doubt this is a novel idea to you guys 😉

Sorry not sorry for the tangent!