Harrow
A thin, macro-free HTTP framework with custom HTTP/1 backends, local-worker runtime architecture, and opt-in observability.
Features
- No macros, no magic -- handlers are plain
async fn(Request) -> Responsefunctions. No extractors, no trait bounds, no#[debug_handler]. - Route introspection -- the route table is a first-class data structure you can enumerate at startup for OpenAPI generation, health checks, or monitoring config.
- Opt-in observability -- structured logging, OTLP trace export, and request-id propagation are wired in with one call, powered by rolly.
- Feature-gated middleware -- request-id, CORS, catch-panic, compression, session, rate-limit, and o11y are opt-in via Cargo features. Nothing compiles unless you ask for it.
- Fast -- custom HTTP/1 transport with shared codec/dispatcher pieces,
matchitrouting, and no Tower orBoxCloneService. - Pluggable server backends -- choose between Tokio/custom HTTP/1 (cross-platform) or Monoio/io_uring (Linux high-performance).
Server Backends (Required)
Harrow requires you to explicitly select an HTTP server backend. There is no default — you must pick exactly one:
| Backend | Feature | Best For | Platform |
|---|---|---|---|
| Tokio + custom HTTP/1 | tokio |
Cross-platform, development, containers | Linux, macOS, Windows |
| Monoio + io_uring | monoio |
Maximum throughput on Linux 6.1+ | Linux 6.1+ only |
Choosing a Backend
Use Tokio for:
- Cross-platform development (macOS, Windows)
- Container deployments (Docker, ECS Fargate, Lambda)
- When you need TLS support (
tlsfeature) - General-purpose HTTP services with the same local-worker/runtime direction as Harrow's other backends
Use Monoio for:
- High-throughput Linux servers (2-3x throughput at 16+ cores)
- Thread-per-core architecture with io_uring
- Bare metal or EC2 deployments with kernel 6.1+
Configuration
# Tokio backend (cross-platform)
[]
= { = "0.10", = ["tokio", "json"] }
= { = "1", = ["full"] } # Required for #[tokio::main] and tokio APIs
# io_uring backend (Linux 6.1+ only)
[]
= { = "0.10", = ["monoio", "json"] }
# Harrow bootstraps monoio worker threads internally via `harrow::runtime::monoio::run(...)`
Explicit Runtime Selection
When both features are enabled (e.g., during development with multiple examples), use the explicit runtime modules:
// Explicit Tokio
use serve;
// Explicit Monoio
use run;
See examples/monoio_hello.rs for a complete Monoio example.
Quickstart
[]
= { = "0.10", = ["tokio"] }
= { = "1", = ["full"] } # Required for #[tokio::main]
use ;
async
async
async
Probes And Error Responses
use ;
use StatusCode;
async
let app = new
.state
.health
.liveness
.readiness_handler
.default_problem_details
.not_found_handler;
Documentation
- Design rationale -- why Harrow exists and what it optimises for
- Local-worker runtime strategy -- the current nginx/ntex-style runtime direction
- HTTP/1 dispatcher design -- how the shared custom backend is structured
- Explicit extractors philosophy -- the design choice behind plain function signatures
- Performance notes -- current benchmark workflow, methodology, and historical results
Workspace layout
| Crate | Purpose |
|---|---|
harrow |
Public API -- re-exports core types and feature-gated middleware |
harrow-core |
Request, Response, routing, middleware trait, app builder |
harrow-middleware |
Request-id, CORS, compression, session, rate-limit, o11y |
harrow-o11y |
O11yConfig and rolly integration types |
harrow-server-tokio |
Tokio custom HTTP/1 backend, local-worker runtime, TLS, graceful shutdown |
harrow-server-monoio |
Monoio/io_uring server for high-performance Linux |
harrow-server-meguri |
Experimental direct io_uring backend |
harrow-bench |
Criterion benchmarks and load testing tools |
License
Licensed under the MIT License.