actix-web (Rust の web フレームワーク)

世の中には言語ごとに様々な web フレームワークがありますが、 actix-web は Rust の web フレームワークです。

なんで actix-web を選んだのかと言えば、「Rust を使いたかった」から。

Rust は数年前に話題になったときに、どんなもんなんだろう？と、 チュートリアルと簡単なツールを作っただけで、それ以降触っていなかったので、 そろそろちゃんと触っておこう、と思ったのが Rust を選択した一番の理由。

特に当時 Rust で作ったツールはシングルスレッドのツールで、 Rust の特性であるデータの排他制御の恩恵やら、 Rust でのマルチスレッドプログラミングのやり方などがさっぱりな状況だったので、 今回改めて Rust を使うことにした。

Rust を選択した理由としては他にも、

• Rust の強力なコンパイラ時のチェックはセキュリティ上も効果があるはず
• gc 系の言語に比べてパフォーマンスも高い

などがあります。

特に、セキュリティは結構気にしている。 というのも、web サービスは攻撃対象になりやすいので、 コンパイラ時にガッツリとチェックされる Rust であれば、 攻撃のスキを与え難いのではないか？と期待していたりします。

まぁ、実際のところどうなのかは不明ですが。。

少なくとも C/C++ よりはマシだとは思うが、 他のイマドキの言語と比べてどうなのか？は良く分からん。

で、 Rust を選んだ理由は上記だが、 じゃぁなんで Rust の中で actix-web なのか、といえば、 Rust の web フレームワークの中で github のスターの数が多かったから。 というそれだけの理由です。

actix-web のリファレンスは以下です。

<https://actix.rs/docs/getting-started/>

前述した通り、 Rust は数年前に少し触った程度ですが、 そんな知識しかない状態でも 上記のリファレンスに従うと簡単な web サービスが動かせました。

とはいえ、 リファレンスのコードそのままなら動くが、 リファレンスのコードそのままで自分の期待する処理は実現できない訳で。

そして、リファレンスのコードから少し外れると、 やっぱり動かなくなる(というかビルドが通らない)訳で。。。

そんな訳で、以降では Rust 初心者、 actix-web 初心者がひっかかるであろう箇所について説明していきます。

actix-web の構成を大まかに分けると、サーバとハンドラからなります。

• サーバの主な役割り

  • path と ハンドラの紐付けの管理
  • サーバがクライアントからアクセスされた時に、 アクセスされた path に従って紐付けられているハンドラをコールする
  • 各ハンドラからアクセスする共有データの管理
  • 指定された port での Listen 処理
  • TLS

• ハンドラの主な役割り

  • サーバによってハンドラが呼びだされ、 要求に対する実際の処理を行なう。

サーバとハンドラの役割を見ると、ハンドラが非常に簡素です。 そして、実際にハンドラはかなり簡単に書けます。

なお、 リクエスト処理に必須の Query の処理や Body の Json パースなども、 ハンドラの引数に指定しておくだけで、自動で行なわれます。

以下のようにすると、 8080 ポートで listen するサーバが起動します。

    HttpServer::new(move || {
        App::new()
            // enable logger
            .wrap(middleware::Logger::default())
            .service(index_test1)
            .route("/hoge", web::get().to(index_test2))
    })
    .bind(("127.0.0.1", 8080))?
    .run()
    .await

ここで、次の部分が path とハンドラの紐付けです。 index_test1, index_test2 はハンドラ関数で、必要な処理を自分で作成します。 ハンドラ関数の名前は任意です。

            .service(index_test1)
            .route("/hoge", web::get().to(index_test2))

この service() , route() は、 それぞれ異なるハンドラ(index_test1, index_test2)の登録処理です。 この登録関数は複数繋げて書けます。

ハンドラの登録は、 service() , route() の2種類で、 service() はハンドラ関数だけ指定し、 route() はサーバ登録時に path と http METHOD とハンドラ関数を指定します。

こう見ると、 service() の方は path と http METHOD の指定なしにどうやって ハンドラを紐付けているのか疑問に感じると思いますが、 それはハンドラのパートで説明します。

ハンドラは、処理に必要なリクエストの Path や Query, JSON などを引数に宣言でき、 戻り値として Json や文字列、 Result 型などを宣言できます。 宣言したハンドラの型に応じて、サーバが良い感じに引数にデータを渡してハンドラを呼び出し、 また宣言したハンドラの戻り値の型に応じてレスポンスを返します。

ハンドラに宣言できる引数と戻り値については、以下を参照してください。

• 引数

  • https://actix.rs/docs/extractors

  • 次の URL で説明されている web::Data<T> 型は、各ハンドラで情報を共有するため 特に重要

    • https://actix.rs/docs/application/#shared-mutable-state
    • web::Data<T> 型の注意点については後述します

• 戻り値

  • https://docs.rs/actix-web/latest/actix_web/trait.Responder.html

  • オススメとしては

    • JSON を返す場合は Json<T>

    • StatusCode をカスタマイズする場合 (R,StatusCode)

      • ここで R には、 Json<T> 等が指定可能
    • StatusCode 以外のヘッダを返す場合は HttpResponseBuilder

引数は、ハンドラの処理に必要なものを複数組み合わせて指定できます。

async fn index( info: actix_web::HttpRequest, mut body: web::Payload ) -> Result<String>

#[get("/hoge")] // /hoge の GET 処理
async fn index( info: actix_web::HttpRequest ) -> Result<String>

use actix_web::{web, App, HttpServer};
use std::sync::Mutex;

struct AppStateWithCounter {
    counter: Mutex<i32>, // <- Mutex is necessary to mutate safely across threads
}

async fn index(data: web::Data<AppStateWithCounter>) -> String {
    let mut counter = data.counter.lock().unwrap(); // <- get counter's MutexGuard
    *counter += 1; // <- access counter inside MutexGuard

    format!("Request number: {counter}") // <- response with count
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    let counter = web::Data::new(AppStateWithCounter {
        counter: Mutex::new(0),
    });

    HttpServer::new(move || {
        App::new()
            .app_data(counter.clone()) // <- register the created data
            .route("/", web::get().to(index))
    })
    .bind(("127.0.0.1", 8080))?
    .run()
    .await
}

struct AppStateWithCounter {
    counter: Mutex<i32>, // <- Mutex is necessary to mutate safely across threads
}

struct AppStateWithCounter {
    counter1: Mutex<i32>,
    counter2: Mutex<i32>,
}

struct CounterSet {
    counter1: i32,
    counter2: i32,
}
struct AppStateWithCounter {
    counterSet: Mutex<CounterSet>,
}

    let counter = web::Data::new(AppStateWithCounter {
        counter: Mutex::new(0),
    });

    HttpServer::new(move || {
        App::new()
            .app_data(counter.clone()) // <- register the created data
            .route("/", web::get().to(index))
    })

async fn index(data: web::Data<AppStateWithCounter>) -> String {

    let mut counter = data.counter.lock().unwrap(); // <- get counter's MutexGuard

    *counter += 1; // <- access counter inside MutexGuard

イマドキの言語で良く見る async/await。

Rust にも async/await があります。

というか、 actix-web は基本となる handler の型が async なので、 async は必須。

で、 async/await の関係については javascript とほとんど同じと考えて良いです。 async の関数は、 await で待たないと処理されずに先に進んでしまうので注意が必要です。

なお、 await は val.await というようにメンバにアクセスするような形で指定します。

また、 await で待てるのは async 関数内のみになります。 この辺りも javascript と同じです。

じゃぁ、 async 関数ではない通常の関数から async の終了を待つにはどうするのかと言うと、 次の block_on() を使う。

<https://docs.rs/actix-web/4.2.1/actix_web/rt/struct.Runtime.html#method.block_on>

ただ、この block_on() を使うのはイマイチな気がします。

というのも、 block_on() を使うには Runtime を作る必要があり、 Runtime を作るには OS リソースが必要です。 そして、Runtime を同時に一定数作ると OS リソースが無くなって Runtime が作れなくなります。 この OS リソースは、Linux の場合はファイルハンドル数(ulimit -n)の制限に依存します。

まぁ、数百くらい同時に Runtime を作った場合の話なので、 実用上あまり気にしなくても良いかもしれないですが、 結構早めに上限が来てしまうことは認識しておいた方が良いでしょう。

そんな訳で、 非 async 関数から async をコールしないように開発を進めるのが基本になります。