Over the next week hyperium/tonic will become grpc/grpc-rust and we will publish a preview release of the new grpc crate. This marks a significant next step for the tonic project and for all gRPC users in Rust as it will be upstreamed to the official gRPC project. The gRPC project is a part of the Cloud Native Computing Foundation (CNCF), a division of The Linux Foundation.

How tonic got here

Before we get into the details, I would like to first give a little summary of the history of tonic. I created the project summer of 2019 mostly because I wanted to write some distributed systems in Rust. Originally, Carl Lerche had written tower-grpc that was being used at Buoyant at the time which provided the perfect initial framework to get started writing a real gRPC library for Rust. This was all around the time async/await was about to release so I had set myself up a target to create the first production ready async/await Rust library. I spent all of my free time building the project trying to get it out the door. Finally in the fall of 2019 I made the first 0.1 release. From that point on the rest is history and the project has now amassed more than 12k stars on github and is being used in many large engineering organizations.

While I am very appreciative of the growth and support the project has brought the community and myself, it has gotten quite hard to maintain. Building new features requires significant time investment and reviewing new changes had become unsustainable with the amount of maintenance resources available to the project. On top of this, the prost project had gone unmaintained and we tonic maintainers had no choice but to adopt it into our family since it was a core dependency. This brought the maintenance burden up significantly. As the years passed and my life changed I started to lose the time needed to fully maintain the project and I was struggling to find maintainers that would stick around. This is a very normal process for large OSS projects and this is a common theme in the OSS community. This has all lead to the project not accepting new features and only really addressing high/urgent priority bugs and most importantly security issues.

What's changing

Fast forward to the start of 2024, I had gotten an email from Doug Fawley from the gRPC team at Google. He had reached out asking if we would be open to collaborating and that he was going to be working on gRPC-Rust and did not want to fracture the ecosystem in an unnecessary way. This was the beginning of gRPC-Rust, since then we have been meeting every week and I have been dedicating my time to helping them figure out how we can best position their needs and the needs of the tonic community.

Over these last two years the team at Google has been working on gRPC-Rust as a new crate that will include many new optimizations and in general bring the gRPC implementation up to the quality bar that the other gRPC implementations are already at. To support this though, there is a new fresh implementation that leverages a new API to support things like controlling allocations, etc. While this is great, there are still a lot of users that use tonic and would not be able to rewrite their code base easily to this new structure. To support our original core tenet of supporting the current community we have also designed any new transport features (non user code gen) to be compatible with tonic's codegen. This means all the new load balancer and thick client features that will be coming to the new transports will be available to current tonic users by changing their channel. This likely means that we will eventually deprecate the old tonic transport to make tonic lighter and transition it to becoming a more ergonomic rusty implementation while still gaining tons of benefits of the new work. We are still working through the details here, and the preview release that will be coming out soon will actually still be based on the tonic transport, but we will be going in this direction as we continue to implement the new client and server in grpc-rust.

One of the benefits of creating this working group has been our ability to find other companies that are interested in contributing. Here is where the folks at LinkedIn have stepped in to contribute one of the most requested and difficult features to implement: xDS. If you do not already know xDS is a discovery service that provides gRPC clients detailed information on how to reach and load balance across a service. It is used as the core protocol for service mesh products like Envoy. It is extremely complex and something that we never had the resources to build in tonic. Thanks to the work that the folks at LinkedIn have done we will be shipping a new tonic-xds crate and then will be reusing the internal machinery to also provide an implementation for the new grpc crate as well.

Joining the CNCF

With all of this work that the working group has done it has finally reached a point where we are ready to upstream the tonic project into the CNCF owned grpc org. I will continue to be a core maintainer of the project but we will be welcoming engineers from Google, LinkedIn and Datadog to help maintain the new and old projects. This is tonic reaching its adulthood and finally reaching for the next level. Rust users can expect a very good and solid production-ready implementation from the gRPC-Rust team over the next year. As we continue with this transition, I encourage everyone to speak up and provide feedback as we continue to forge a path for the old and new.