An RPC framework for Rust with a focus on ease of use.
Alternatives To Tarpc
Project NameStarsDownloadsRepos Using ThisPackages Using ThisMost Recent CommitTotal ReleasesLatest ReleaseOpen IssuesLicenseLanguage
a year ago27September 14, 2020188apache-2.0PHP
🚀 PHP Microservice Full Coroutine Framework
Grpcui4,412172 days ago23August 04, 202252mitGo
An interactive web UI for gRPC, along the lines of postman
Cellnet3,87879 months ago3March 11, 20218mitGo
High performance, simple, extensible golang open source network library
Magiconion3,3449344 days ago76June 05, 202322mitC#
Unified Realtime/API framework for .NET platform and Unity.
Tarsgo3,22429a month ago48June 28, 202310bsd-3-clauseGo
A high performance microservice framework in golang. A linux foundation project.
Tarpc2,76763314 days ago46April 03, 202344mitRust
An RPC framework for Rust with a focus on ease of use.
Fbthrift2,48814a day ago94April 04, 202247apache-2.0C++
Facebook's branch of Apache Thrift, including a new C++ server.
a year ago8June 21, 202120apache-2.0Go
Scalable Distributed Game Server Engine with Hot Swapping in Golang
X1,6592210911 days ago391September 03, 20235mitC#
Core basic components: log (file / network), configuration (XML / JSON / HTTP), cache (memory / redis), network (TCP / UDP / HTTP), RPC framework, serialization (binary / XML / JSON), APM performance tracking. 核心基础组件,日志(文件/网络)、配置(XML/Json/Http)、缓存(内存/Redis)、网络(Tcp/Udp/Http)、RPC框架、序列化(Binary/XML/Json)、APM性能追踪。
10 months ago98otherC++
rpclib is a modern C++ msgpack-RPC server and client library
Alternatives To Tarpc
Select To Compare

Alternative Project Comparisons

Crates.io MIT licensed Build status Discord chat


Disclaimer: This is not an official Google product.

tarpc is an RPC framework for rust with a focus on ease of use. Defining a service can be done in just a few lines of code, and most of the boilerplate of writing a server is taken care of for you.


What is an RPC framework?

"RPC" stands for "Remote Procedure Call," a function call where the work of producing the return value is being done somewhere else. When an rpc function is invoked, behind the scenes the function contacts some other process somewhere and asks them to evaluate the function instead. The original function then returns the value produced by the other process.

RPC frameworks are a fundamental building block of most microservices-oriented architectures. Two well-known ones are gRPC and Cap'n Proto.

tarpc differentiates itself from other RPC frameworks by defining the schema in code, rather than in a separate language such as .proto. This means there's no separate compilation process, and no context switching between different languages.

Some other features of tarpc:

  • Pluggable transport: any type implementing Stream<Item = Request> + Sink<Response> can be used as a transport to connect the client and server.
  • Send + 'static optional: if the transport doesn't require it, neither does tarpc!
  • Cascading cancellation: dropping a request will send a cancellation message to the server. The server will cease any unfinished work on the request, subsequently cancelling any of its own requests, repeating for the entire chain of transitive dependencies.
  • Configurable deadlines and deadline propagation: request deadlines default to 10s if unspecified. The server will automatically cease work when the deadline has passed. Any requests sent by the server that use the request context will propagate the request deadline. For example, if a server is handling a request with a 10s deadline, does 2s of work, then sends a request to another server, that server will see an 8s deadline.
  • Distributed tracing: tarpc is instrumented with tracing primitives extended with OpenTelemetry traces. Using a compatible tracing subscriber like Jaeger, each RPC can be traced through the client, server, and other dependencies downstream of the server. Even for applications not connected to a distributed tracing collector, the instrumentation can also be ingested by regular loggers like env_logger.
  • Serde serialization: enabling the serde1 Cargo feature will make service requests and responses Serialize + Deserialize. It's entirely optional, though: in-memory transports can be used, as well, so the price of serialization doesn't have to be paid when it's not needed.


Add to your Cargo.toml dependencies:

tarpc = "0.33"

The tarpc::service attribute expands to a collection of items that form an rpc service. These generated types make it easy and ergonomic to write servers with less boilerplate. Simply implement the generated service trait, and you're off to the races!


This example uses tokio, so add the following dependencies to your Cargo.toml:

anyhow = "1.0"
futures = "0.3"
tarpc = { version = "0.31", features = ["tokio1"] }
tokio = { version = "1.0", features = ["macros"] }

In the following example, we use an in-process channel for communication between client and server. In real code, you will likely communicate over the network. For a more real-world example, see example-service.

First, let's set up the dependencies and service definition.

use futures::{
    future::{self, Ready},
use tarpc::{
    client, context,
    server::{self, incoming::Incoming, Channel},

// This is the service definition. It looks a lot like a trait definition.
// It defines one RPC, hello, which takes one arg, name, and returns a String.
trait World {
    /// Returns a greeting for name.
    async fn hello(name: String) -> String;

This service definition generates a trait called World. Next we need to implement it for our Server struct.

// This is the type that implements the generated World trait. It is the business logic
// and is used to start the server.
struct HelloServer;

impl World for HelloServer {
    // Each defined rpc generates two items in the trait, a fn that serves the RPC, and
    // an associated type representing the future output by the fn.

    type HelloFut = Ready<String>;

    fn hello(self, _: context::Context, name: String) -> Self::HelloFut {
        future::ready(format!("Hello, {name}!"))

Lastly let's write our main that will start the server. While this example uses an in-process channel, tarpc also ships a generic [serde_transport] behind the serde-transport feature, with additional TCP functionality available behind the tcp feature.

async fn main() -> anyhow::Result<()> {
    let (client_transport, server_transport) = tarpc::transport::channel::unbounded();

    let server = server::BaseChannel::with_defaults(server_transport);

    // WorldClient is generated by the #[tarpc::service] attribute. It has a constructor `new`
    // that takes a config and any Transport as input.
    let mut client = WorldClient::new(client::Config::default(), client_transport).spawn();

    // The client has an RPC method for each RPC defined in the annotated trait. It takes the same
    // args as defined, with the addition of a Context, which is always the first arg. The Context
    // specifies a deadline and trace information which can be helpful in debugging requests.
    let hello = client.hello(context::current(), "Stim".to_string()).await?;



Service Documentation

Use cargo doc as you normally would to see the documentation created for all items expanded by a service! invocation.

License: MIT

Popular Rpc Projects
Popular Server Projects
Popular Application Programming Interfaces Categories
Related Searches

Get A Weekly Email With Trending Projects For These Categories
No Spam. Unsubscribe easily at any time.
Asynchronous Programming
Rpc Framework