tchigher / tower

fn(Request) -> Future<Response>

Tower

Tower is a library of modular and reusable components for building robust networking clients and servers.

Overview

Tower aims to make it as easy as possible to build robust networking clients and servers. It is protocol agnostic, but is designed around a request / response pattern. If your protocol is entirely stream based, Tower may not be a good fit.

Project Layout

Tower consists of a number of components, each of which live in their own sub crates.

• tower: The main user facing crate that provides batteries included tower services (docs).

• tower-service: The foundational traits upon which Tower is built (docs).

• tower-layer: The foundational trait to compose services together (docs).

• tower-balance: A load balancer. Load is balanced across a number of services (docs).

• tower-buffer: A buffering middleware. If the inner service is not ready to handle the next request, tower-buffer stores the request in an internal queue (docs).

• tower-discover: Service discovery abstraction (docs).

• tower-filter: Middleware that conditionally dispatch requests to the inner service based on a predicate (docs).

• tower-limit: Middleware limiting the number of requests that are processed (docs).

• tower-reconnect: Middleware that automatically reconnects the inner service when it becomes degraded (docs).

• tower-retry: Middleware that retries requests based on a given Policy (docs).

• tower-test: Testing utilies (docs).

• tower-timeout: Middleware that applies a timeout to requests (docs).

• tower-util: Miscellaneous additional utilities for Tower (docs).

Status

Currently, only tower-service, the foundational trait, has been released to crates.io. The rest of the library will be following shortly.

License

This project is licensed under the MIT license.

Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in Tower by you, shall be licensed as MIT, without any additional terms or conditions.