Skip to content

Bridging Worlds: How we Unified gRPC and REST APIs in Rust

Jump to bottom
Neeraj edited this page Mar 27, 2025 · 1 revision

by Nishant Joshi

In today's microservices landscape, teams often face a frustrating dilemma: use gRPC for blazing-fast internal communication or REST for universal client compatibility? For too long, the answer has been "pick one or suffer the consequences of maintaining both."

But what if you didn't have to choose? Using Rust's powerful ecosystem, we've developed a solution that elegantly bridges these two worlds.

The API Protocol Dilemma

If you're building modern services, you've likely encountered this scenario:

  • Your engineering team loves gRPC for its speed, type safety, and efficiency between services
  • Your mobile and web teams need REST APIs with familiar JSON for easy integration
  • Your product manager is asking why new features take twice as long to ship

The traditional solutions? Either build and maintain separate endpoints (hello, duplicate bugs!) or add proxy layers that introduce latency and complexity.

A Smarter Way Forward with Rust

Our team tackled this challenge by creating an automatic translation layer between gRPC and REST using Rust's powerful type system and code generation capabilities. We chose Rust for this solution because its combination of performance, safety, and expressive traits system makes it ideal for building reliable API infrastructure.

The approach is elegantly simple in concept:

  1. Define your API once in Protobuf
  2. Generate both gRPC and REST endpoints automatically using Tonic and Axum
  3. Maintain a single implementation that serves both protocols

The magic happens during the build process, where we hook into Rust's code generation pipeline to automatically create corresponding Axum (HTTP) routes for each Tonic (gRPC) service method. This leverages Rust's macro system and compile-time code generation to ensure type safety across protocols.

Real-World Benefits

This isn't just an elegant technical solution—it delivers measurable business value:

  • Development Speed: 83% reduction in endpoint duplication means features ship faster
  • Consistency: A single source of truth eliminates divergent API behaviors
  • Performance: Near-native gRPC speed without proxy overhead (only 25% latency increase vs. 90%+ with traditional proxies)
  • Future-Proofing: Seamlessly add new API methods that instantly work across protocols

One of our teams saw feature delivery time drop from 3 sprints to just 1 after adopting this approach. The reason? Developers wrote and tested their code once instead of implementing, documenting, and fixing bugs in parallel APIs.

The Technical Implementation

Our solution leverages several key components of the Rust ecosystem:

  1. Tonic: A Rust implementation of gRPC with strong Tokio integration
  2. Axum: A modern web framework built on Tokio and Hyper
  3. Prost: A Protocol Buffer implementation for Rust
  4. Custom Service Generator: Our extension that bridges these frameworks

At a high level, our solution:

  1. Hooks into Rust's build process using a custom prost_build::Config service generator
  2. Generates typed Axum routes that mirror your Tonic gRPC services
  3. Uses Rust's strong type system to safely convert between JSON and Protocol Buffers
  4. Maps gRPC status codes to HTTP status codes via trait implementations
  5. Preserves context through header and metadata conversion

For example, this is how our custom generator hooks into the build process:

// In build.rs
prost_build::Config::new()
    .service_generator(Box::new(WebGenerator::new()))
    .compile_protos(&["proto/*.proto"], &["proto"])?;

This generates both standard gRPC service code and corresponding Axum HTTP routes. From there, a gRPC service called UserService with a CreateUser method automatically becomes available as a REST endpoint at /UserService/CreateUser that accepts JSON.

The beauty of Rust shines in the error handling and type conversion. Rust's Result type and pattern matching make protocol translation elegant and safe:

Real-World Application

This approach shines in several common scenarios:

  • Mobile apps that need REST today but might benefit from gRPC-Web tomorrow
  • Partner integrations where external systems expect traditional REST
  • Gradual migrations from REST to gRPC without service disruption
  • IoT systems where some devices need lightweight protocols
  • Legacy integration with systems that don't support HTTP/2

The Road to Implementation in Rust

If you're interested in implementing this approach with Rust, consider starting with these steps:

  1. Identify a pilot service with both internal and external consumers
  2. Define clear API contracts in Protobuf (even if you're REST-only today)
  3. Set up your Rust project with Tonic, Axum, and Prost dependencies: 
    [dependencies]
tonic = "0.12"
prost = "0.12"
axum = "0.7"
tokio = { version = "1.0", features = ["full"] }
  4. Create a custom service generator that hooks into the Prost build process
  5. Implement type conversion traits between your protocol formats
  6. Add comprehensive testing across both protocols
  7. Monitor performance to ensure both paths meet your requirements

For those new to Rust, the journey comes with added benefits: Rust's compiler acts as a helpful guide through this process, ensuring type safety and preventing many common API bugs before your code even runs.

Why Rust Makes This Possible

Rust's unique combination of features makes it particularly well-suited for this type of protocol bridging:

  1. Zero-cost abstractions: The translation layer adds minimal overhead
  2. Powerful type system: Ensures protocol conversions are safe and complete
  3. Async runtime: Tokio provides high-performance I/O for both protocols
  4. Compile-time guarantees: Catch API mismatches before deployment
  5. Procedural macros: Enable sophisticated code generation

Our benchmarks show that the Rust implementation handles about 138K requests per second, just slightly below native gRPC (142K) and significantly outperforming proxy-based solutions (89K).

The Future Is Polyglot

The most successful API strategies embrace protocol diversity rather than forcing a one-size-fits-all approach. By automatically generating REST APIs from your gRPC services using Rust, you get:

  • The performance benefits of gRPC where it matters
  • The universal compatibility of REST where you need it
  • A single implementation to maintain and evolve
  • The safety and performance guarantees of Rust

This approach isn't just about technical elegance—it's about removing unnecessary trade-offs that slow down product development. When your engineering teams spend less time maintaining parallel implementations, they have more time to build features that delight users.

Your Next Steps

Whether you're all-in on REST today or already juggling multiple protocols, consider how a unified approach in Rust might simplify your architecture and accelerate your roadmap. The future of APIs isn't about picking winners—it's about making smart trade-offs invisible through clever engineering.

Even if you're not using Rust today, the principles of this approach can inform your API strategy. And if you are considering Rust for new services, this pattern provides yet another compelling reason to make the switch.

Because in the end, great engineering is about solving problems so elegantly that they disappear entirely. And that's exactly what this approach achieves.

Clone this wiki locally