tower-rs/tower

async fn(Request) -> Result<Response, Error>

View on GitHub ↗Jump to charts ↓Open shareable report

Summary Information

Updated 35 minutes ago
Added to GitGenius on September 16th, 2026
Created on July 24th, 2017
Open Issues & Pull Requests: 99 (+0)
GitHub issues: Enabled
Number of forks: 344
Total Stargazers: 4,298 (+0)
Total Subscribers: 48 (+0)

Repository Insights (GitGenius)

Median issue/PR response: 18.7 hours
Mean response time: 62.7 days
90th percentile: 263.6 days
Tracked items: 29

Most active contributors

Sign in to see contributor activity.

How this project is maintained

73% of open issues come from outside the core team, so the backlog reflects real-world use rather than internal planning. Three people close 75% of everything that gets resolved.

Charts & Analytics

Fetching additional details & charts...

Issue Activity (beta)

Open issues: 26
New in 7 days: 0
Closed in 7 days: 0
Avg open age: 771 days
Stale 30+ days: 25
Stale 90+ days: 23

Recent activity

Opened in 7 days: 0
Closed in 7 days: 0
Comments in 7 days: 0
Events in 7 days: 0

Top labels

  • A-tower (2)
  • C-feature-request (2)
  • E-easy (2)
  • I-needs-decision (2)
  • T-docs (2)
  • A-balance (1)
  • A-service (1)
  • A-util (1)

Detailed Description

Tower is a library for building and composing asynchronous services in Rust using a middleware-oriented architecture.

The library addresses the challenge of building robust, composable network services by providing abstractions that treat services as simple async functions transforming requests into responses. Tower's core insight is that middleware, load balancing, retries, timeouts, and other cross-cutting concerns can be cleanly separated and composed as layers around a core service. The approach works by defining a Service trait that represents any asynchronous operation accepting a request and returning a result, allowing developers to build middleware as decorators that wrap existing services and modify their behavior.

Tower suits projects where you need to handle distributed systems concerns like rate limiting, circuit breaking, or request routing without coupling those concerns to business logic. It works well for building HTTP clients and servers, gRPC services, and other network applications where middleware composition is valuable. The library is particularly useful when you want to reuse middleware across different service implementations or when you need to test services in isolation from their middleware stack.

The project shows sustained development with regular commits addressing bug fixes and incremental improvements. Discussions in issues reflect engagement with user questions and feature requests. Pull requests receive review attention, indicating active maintenance of code quality. The codebase demonstrates a focus on stability and backward compatibility rather than rapid feature expansion.