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.

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.

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

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

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

It looks pretty abandoned.

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

@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.

Very nice!

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

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!

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.

@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.

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.

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.

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.