liveBook · Manning

Actix Web

As explained in Latency

Actix is a Rust framework for building actor-based applications.

Actix Web is a Rust framework for building HTTP services. It provides an HTTP server and application router, where resources such as /hello are connected to asynchronous request handlers. section 3.5

A typical service creates shared application state, registers routes, binds an HttpServer, and runs it asynchronously. Database access can be placed in handlers through shared connection pools or synchronized connections. section 3.5

The framework appears in two related systems-programming contexts:

  • Supports actor-based concurrency through Actix: actors encapsulate state, receive messages, and avoid explicit state synchronization because the runtime schedules handlers without concurrent access. section 9.2.6
  • Builds REST endpoints backed by PostgreSQL or SQLite, allowing database choice and connection strategy to affect observed latency. section 3.5
  • Introduces asynchronous execution and distributed communication benefits alongside nonlinear message flow and debugging challenges. section 9.2.6

A minimal database-backed endpoint

A service can register /hello, obtain a PostgreSQL connection from a pool, execute SELECT 'hello world', and return the resulting string. A wrk run using two threads and ten connections measured 1,460.66 requests per second, 8.06 ms average latency, and 33.75 ms latency at the 99th percentile. The SQLite variant reached 188,469.82 requests per second with 41 microseconds median latency, while its tail remained near 15 milliseconds versus roughly 60 milliseconds for PostgreSQL in the latency distribution comparison. section 3.5

Listing 3.1 REST API server scaffolding with PostgreSQL
#[tokio::main]
async fn main() -> anyhow::Result<()> {
    let pool = create_pool()?;
    let app = move || {
        App::new()
            .app_data(web::Data::new(pool.clone()))
            .service(
                web::resource("/hello")
                    .route(web::get().to(say_hello)),
            )
    };
    Ok(HttpServer::new(app)
        .bind("127.0.0.1:8080")?
        .run()
        .await?)
}

The scaffold shows the operational shape of an Actix Web service: create shared state, register a resource and route, bind the server, and await its run future. section 3.5

How Latency covers it

How deep it goes
Shows runnable server scaffolding, handlers, database integration, actor state handling, and latency measurements.
Examples
Uses a counter actor, a /hello endpoint, PostgreSQL and SQLite backends, wrk measurements, and latency distribution plots.
What it assumes
Assumes Rust and database tooling, while demonstrating routing, handlers, shared state, asynchronous startup, and actor message handling.
What you can do after
Builds a Rust REST service, connects it to a database, and evaluates latency with wrk or a custom benchmark.
How it connects
Connects HTTP servers and REST APIs with asynchronous execution, actor models, PostgreSQL, SQLite, connection pooling, and benchmarking.
Cover of Latency
liveBookmanning.com
Read Latency on liveBook Get the book at manning.com

Also explained in

Compare how 2 books explain Actix Web →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Latency. The section links point to the parts of the book it draws on.