Lucio Franco

Tonic is joining the gRPC project

2026-05-19T10:00:00-04:00

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

How tonic got here</h2> Before we get into the details, I would like to first give a little summary of the history of tonic</code>. 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</code> 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</code> project had gone unmaintained and we tonic</code> 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</h2> 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</code> 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</code>'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</code> users by changing their channel. This likely means that we will eventually deprecate the old tonic transport to make tonic</code> 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</code> crate and then will be reusing the internal machinery to also provide an implementation for the new grpc</code> crate as well. Joining the CNCF</h2> 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</code> project into the CNCF owned grpc</code> 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</code> 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.

Tonic: 0.2 with the future in mind!

2020-04-01T10:00:00-04:00

Tonic: 0.2 release with the future in mind!</h1>
After a few months of work we finally have released `tonic</code> 0.2. This release marks the start of a new path for tonic</code>.`

Generic encoding</h2> Originally, tonic</code> was a wrapper around hyper</code>, tower</code> and prost</code> providing a good out of the box experience for protobuf based gRPC services. With 0.2 tonic</code> still provides a great out of box experience for protobuf but now also supports other encoding formats! tonic</code> has always supported custom codecs via the tonic::codec::Codec</code> trait but codegen would always tie directly to prost</code>. Which means that if you wanted to write a custom codec you would have to manually replicate what tonic-build</code> does. This is no longer true as we now have traits that can be implemented within tonic-build</code> to guide codegen in the correct direction.
`In the future, tonic</code> will also provide support for flatbuffers via the new work in-progress``butte</code></a> crate! tonic</code> 0.2 supports the groundwork for this and we will create an accompanying crate that will provide all the types you need in the future.`

Healthchecks</h2> Another common feature request has been providing a way to support gRPC healthchecks. After some work @jen20</a> has implemented the tonic-health</code> crate which provides support for server side health reporting. let (mut health_reporter, health_service) = tonic_health::server::health_reporter(); // Set our Greeter service to serving. health_reporter .set_serving::<GreeterServer<MyGreeter>>() .await; // Add healthcheck service to our router Server::builder() .add_service(health_service) .add_service(GreeterServer::new(greeter)) .serve(addr) .await?; </code></pre> Example can be found here</a>. v0.2.0</h2> Thanks to all the wonderful contributors for helping get this release over the finish line. As always, there is a changelog</a> and an issue</a> tracker if you run into any issues. Please, feel welcome to also join us on discord</a> if you need any help!

Tonic: 0.1 has arrived! 2020-01-14T10:00:00-04:00 Tonic: 0.1 has arrived!</h1> tonic</code></a> is a gRPC over HTTP/2 implementation focused on high performance, interoperability, and flexibility. It has been a few months since I originally released the 0.1.0-alpha.1</code> version. Since then there has been a ton of growth and improvements. We've seen 32 new contributors</code></a>, two new guides</code></a>, 8 more examples</code></a> and 5 releases</code></a>. Not only have we seen a lot of growth internally but we've also seen a large amount of adoption. Changes</h2> Since the first 0.1.0-alpha.1</code> release, Tonic made several ergonomic changes. Upgrades EVERYWHERE</h3> Tonic was originally released as an alpha because a majority of the crates it depended on were also alphas. 0.1</code> signifies that all our dependencies are as lean as possible. For instance: syn</code> and quote</code> are at 1.0, bytes</code> is set to 0.5 and hyper</code> is at 0.13 Thanks to all the maintainers for helping push out all these releases! Also, I would like to note that cargo-deny</code></a> has been very helpful in ensuring that we have no duplicate dependencies! Goodbye openssl, hello rustls</h3> The build-in transport module no longer supports openssl</code>. Instead, Tonic defaults to rustls</code>, which should simplify building Tonic-based applications and libraries. However, I recognize that Tonic users might want to use a different TLS library, so Tonic supports customization via constructor client</a> and constructor server</a>. Interceptors</h3> Tonic also supports gRPC interceptors (non-gRPC ecosystems might refer to “interceptors” as “middleware”). Like the name suggests, interceptors allow clients and servers to intercept a request and perform an arbitrary action, like adding headers to sign a request or logging a request. See the example below: #[tokio::main] async fn main() -> Result<(), Box<dyn std::error::Error>> { let channel = Endpoint::from_static("http://[::1]:50051") .connect() .await?; let mut client = GreeterClient::with_interceptor(channel, intercept); // snip } /// This function will get called on each outbound request. Returning a /// `Status` here will cancel the request and have that status returned to /// the client. fn intercept(req: Request<()>) -> Result<Request<()>, Status> { println!("Intercepting request: {:?}", req); Ok(req) } </code></pre> One key thing to note here is that these interceptors are transport agnostic. They are pure gRPC, it does not matter where you get the request from, it could be via grpc-web</code> or http2</code>. More examples of this usage can be found here</code></a>. v0.1.0</h2> I'd like to give a special shoutout to all those that helped the project grow by opening issues, trying Tonic out and opening PRs. That said, I am super happy to finally release the 0.1</code> release of tonic</code>. This is the first stepping stone in a great ecosystem built on top of tower</code></a>. As always, there is a changelog</a> and an issue</a> tracker if you run into any issues. Please, feel welcome to also join us on discord</a> if you need any help! Tonic: gRPC has come to async/await! 2019-10-02T10:00:00-04:00 Tonic: gRPC has come to async/await!</h1> I am pleased to finally announce a crate that I have been working very hard on for the past few months. tonic</code></a> has finally hit the initial 0.1.0-alpha.1</code></a> release! Stable releases will follow in the coming months. What is Tonic?</h3> Tonic is a gRPC-over-HTTP/2 implementation focused on high performance, interoperability, and flexibility. This library was created to have first class support of async/await and to act as a core building block for production systems written in Rust. </blockquote> Tonic began its life as tower-grpc</code></a>, which was built to satisfy linkerd</a>'s need for a production-ready gRPC implementation. tower-grpc</code></a> was based upon futures 0.1</code> and built ontop of the tower</code></a> library, which has production uses in systems such as the linkerd-proxy</code></a>, vector</code></a>, and the noria</code></a> database at MIT. The tower</code></a> library has also seen usage in additional libraries such as warp</code></a>, tower-web</code></a>, and actix-net</code></a>. With async/await’s forthcoming stabilization, we created Tonic to support the new syntax natively. This means clients will support async/await out of the box and server implementations can be defined via async_trait</code></a>s. This provides an unparalleled experience for writing async services quickly and efficiently. Not only does Tonic provide a fully featured gRPC implementation but it also comes with a fully featured, batteries-included, HTTP/2 client and server built around hyper</code></a>, tokio</code></a> and tower</code></a>. Both the client and server implementation provide TLS backed by either openssl</code></a> or rustls</code></a>. The client provides load balancing, interceptors (middleware), timeouts, rate limiting, concurrency control and more! Tonic also boasts strong interoperability and correctness. Every commit is checked that it passes the gRPC interop test cases</a> against the grpc-go</code></a> implementation. Hopefully, more languages can be added in the future. Features</h3> Tonic's goal is to provide a good batteries-included experience. It already supports many features, with many more planned! Here is a list of features: Implemented in pure Rust (minus openssl</code></a> which is optional)</li> Interoperability tested via tonic-interop</code></a></li> Bi-directional streaming</li> Custom metadata</li> Trailing metadata</li> Codegen via prost</code></a></li> Exposes tracing</code></a> diagnostics</li> Fully featured HTTP/2 client and server based on hyper</code></a></li> TLS backed by either openssl</code></a> or rustls</code></a></li> Load balancing powered by tower</code></a></li> Reliability features such as timeouts, rate limiting, concurrency control, and more</li> gRPC interceptors</li> And much more to come</li> </ul> Overview</h3> helloworld client example: let mut client = GreeterClient::connect("http://[::1]:50051")?; let request = Request::new(HelloRequest { name: "hello".into(), }); let response = client.say_hello(request).await?; println!("RESPONSE={:?}", response); </code></pre> This shows how easy it is to build a simple gRPC client using code generated by the tonic-build</code></a> crate. Internally, connect</code> will create the most basic "channel/client" but it is possible to configure this to support TLS, load balancing, timeouts and more. helloworld server example: #[tonic::async_trait] impl Greeter for MyGreeter { async fn say_hello(&self, req: Request<HelloRequest>) -> Result<Response<HelloReply>, Status> { println!("Got a request: {:?}", req); let reply = HelloReply { message: "Zomg, it works!".into(), }; Ok(Response::new(reply)) } } </code></pre> Servers are simple to implement using dtolnay</code></a>'s amazing async_trait</code></a> crate, which allow server implementations to use async fn</code> for their implementation. The tonic-examples</code></a> crate demonstrates more advanced cases with TLS, authentication, load balancing, streaming and more. Moving forward</h3> Today marks Tonic's first alpha release, and over the next few months we will be working hard to ensure that Tonic is ready for production usage. A lot of the implementation has already been proven in production environments via tower-grpc</code></a>. Over the next few months as tokio</code></a> 0.2 comes closer to a full stable release, Tonic will follow with its own stable releases. Conclusion</h3> tonic</code></a> is now available! There is documentation</a>, examples</a> and an issue</a> tracker! Please provide any feedback, as we would love to improve this library any way we can! Thank you to all the super awesome contributors that have helped over the past few months! Your feedback has been immensely important and valuable! Amethyst: The Gem in the Rust 2018-10-28T13:00:00-04:00 Amethyst: The Gem in the Rust</h1> I originally wrote this all up in preparation for the talk I gave at the Rust NYC October Meetup in 2018. The slides are available here</a>. This is just a translation of what I said but in blog form What is a Game Engine?</h2> A game engine is usually just a collection of libraries that are glued together to provide easy utilities to build a game. This includes things like asset loading (think PNG files and 3D models), render utilities (think of things that allow you to draw stuff without thinking of the lower level code), input capturing, and UI Components. Game engines usually become very large code bases. They can grow very quickly which makes it hard to maintain a uniform API and verify consistency across the whole project. Engine components are usually very tightly coupled, meaning that the dependency graph can get CRAZY. This part relies on that part which relies back on that part. It gets hectic! Because of this coupling, it creates issues with parallelization and memory safety. What is Amethyst?</h2> Amethyst is, you guessed right, a game engine! It is built up of many small modular components (crates) that can be used independently from each other or can be used together glued by the amethyst</code> crate. The backbone of the project is an Entity Component System or ECS. An Entity Component System is a method to describe the game state. It follows the pattern of composition over inheritance. This pattern fits rusts trait system extremely well. The ECS setup allows the engine to be data-oriented and data-driven. Both of these combined allows the engine to have parallelism at its core. Using composition also allows the user to focus on reusability and clean interfaces. History</h2> The project was originally created as a hobby game engine by Eyal</a> in early 2016. It soon started to grow and required a movement to an organization. From this organization and its members, Specs</a> was born. Specs is the ECS library that amethyst is built off of. From this library, libraries such as Shred</a> were born to provide utilities on top of specs to take advantage of the parallel and data-oriented nature. Now, Amethyst is growing as a top choice for an all-purpose rust game engine. There are other similar libraries but none of them attempt to achieve what Amethyst is trying to do. Currently, the repository sits at 35.7K (as of October 2018) lines of code. Not that this means too much but more a measure of the scale of the project. This size is only the engine and does not include its external dependencies. We have a book that is growing day by day. It includes almost fully featured pong tutorial and other useful insights. We have 22 examples from hello world to advanced gLTF loading. Amethyst, currently fully supports all three main operating systems with a future goal of supporting iOS, Android and WASM. The list of features is HUGE, we have modular rendering system built from gfx, which is a multi-backend graphics API. Meaning, it can support OpenGL, Metal, Vulkan, and DirectX based APIs. There is support for gamepads and controllers. Multiplayer, User interfaces, animations, ECS, Inputs, Configuration loading via Rust object notation, think JSON but for Rust. Asset loading and an advanced state manager. The future holds a lot for the engine, we are currently, working on a new renderer that will take advantage of the new modern rendering APIs such as Vulkan and Metal. Better networking, this is the area that I focus on, there is work going into a semi-reliable UDP protocol for game networking. Editors, scripting, future support for WASM and WebGL, (write your game in rust that runs anywhere a browser can!). Mobile support and a REPL. How does Rust Help?</h2> Now, why use rust for this project, and why is this the future of game development. Rust supports awesome parallelization primitives in the standard library. Such as RwLocks, AtomicPtr, and others. It also has great libraries for this stuff including crossbeam and rayon. This allows specs and the ECS system to be really fast. Not only does it help with speed but it also lets us take advantage of the new rendering APIs that are no longer single-thread based. Meaning that we can dispatch render calls from any thread. Easy to build and support rendering optimizations such as frame graphs. More writing code and less tracing data races and segfaults, but I'm sure you all have heard this enough. The compiler is your best friend in Rust after you learn to properly use the borrow checker. The type safety and checking provide ease of use when it comes to producing high-quality code that WORKS. Trait composition fits very nicely into the ECS model. Type inference allows you to focus on the contracts that functions provide and reduce the amount of typing needed to accomplish something. Bugs, the compiler just stops you from producing a whole class of bugs. This is a sanity check for game developers who want to release a game and sleep at night. Cargo is my favorite package manager, it's simple, easy to use and does a great job. It allows us to build, run and test our whole project incredibly easily. We can run benchmarks to find regressions or just see how fast our code is. Built-in documentation allows us to provide a documentation first perspective. Instead of approaching new people with "get good" we can approach it all by saying, we should add this to the docs. This promotes a great community atmosphere but also improves the docs for future users. Cargo also does a great job at dependency management and making sure our code doesn't get broken. These are just a few of the improvements a rust game engine has over say a C++ one. Getting started!</h2> Check out the Amethyst</a> website. Come join us on discord! About 2018-10-02T22:56:31-04:00 I am a West coast based software engineer who maintains open source projects and works in Rust.

v0.2.0</h2>
Thanks to all the wonderful contributors for helping get this release over the finish line. As always, there is a changelog</a> and an issue</a> tracker if you run into any issues. Please, feel welcome to also join us on discord</a> if you need any help!</p>

Tonic: gRPC has come to async/await!</h1>
I am pleased to finally announce a crate that I have been working very hard on for the past few months. `tonic</code></a> has finally hit the initial` `0.1.0-alpha.1</code></a> release! Stable releases will follow in the coming months.</p>`

Amethyst: The Gem in the Rust</h1>
I originally wrote this all up in preparation for the talk I gave at the Rust NYC October Meetup in 2018. The slides are available here</a>. This is just a translation of what I said but in blog form</em></p>

Getting started!</h2>
Check out the Amethyst</a> website. Come join us on discord!</p>

Lucio Franco

Tonic is joining the gRPC project

Tonic: 0.2 with the future in mind!

Tonic: 0.2 release with the future in mind!</h1>
After a few months of work we finally have released `tonic</code> 0.2. This release marks the start of a new path for tonic</code>.</p>`

Tonic: 0.1 has arrived!

Tonic: gRPC has come to async/await!

Amethyst: The Gem in the Rust

About

Lucio Franco

Tonic is joining the gRPC project

Tonic: 0.2 with the future in mind!

Tonic: 0.2 release with the future in mind!</h1> After a few months of work we finally have released tonic</code> 0.2. This release marks the start of a new path for tonic</code>.</p>

Tonic: 0.1 has arrived!

Tonic: gRPC has come to async/await!

What is Tonic?</h3> Tonic is a gRPC-over-HTTP/2 implementation focused on high performance, interoperability, and flexibility. This library was created to have first class support of async/await and to act as a core building block for production systems written in Rust.</p> </blockquote>

Overview</h3> helloworld client</strong> example:</em></p>

Amethyst: The Gem in the Rust

About

Tonic: 0.2 release with the future in mind!</h1>
After a few months of work we finally have released `tonic</code> 0.2. This release marks the start of a new path for tonic</code>.</p>`