インストール

Rust ツールチェーンリンクをコピー

wakuwaku は Rust edition 2024 で書かれているため、Rust 1.85 以上が必要です。さらに依存クレートによって下限が引き上げられます。wakuwaku 1.0.0-rc3 でロックされているバージョンでは、有効にするフィーチャーごとに次のとおりです。

これらの依存の新しいリリースでさらに下限が上がる可能性があるため、最新の stable ツールチェーンを使ってください。

rustup update stable

gRPC のコード生成には、Protocol Buffers コンパイラ protoc が PATH 上に必要です。ビルドスクリプトは クイックスタート で紹介します。

wakuwaku を追加するリンクをコピー

必要なフィーチャーを指定して wakuwaku を追加し、ランタイム用に tokio も追加します。

[dependencies]
wakuwaku = "1.0.0-rc3" # デフォルト: grpc, proof
tokio = { version = "1.53", features = ["full"] }

entity は sqlx-pg、sqlx-mysql、redis、meilisearch のどれかを有効にすると自動で有効になります。entity だけを有効にするのは、データソースなしでクエリやケイパビリティの型だけを使いたい場合 (たとえばインメモリストア向けのクエリを定義するクレート) に限られます。

wakuwaku::deps を使う理由リンクをコピー

あるクレートのあるバージョンの型は、別バージョンの同じアイテムとは別の型です。サービスが sqlx 0.8 に依存し、wakuwaku が sqlx 0.9 を使っていると、自分で作ったプールは wakuwaku::entity が受け取るプールとは別物になり、読み解きにくい型の不一致エラーになります。

wakuwaku は、公開 API に現れるサードパーティのクレートをすべて再エクスポートすることでこの問題を避けています。

これらのクレートを自分で追加する代わりに、次のパスからインポートします。

use wakuwaku::deps::kanau::processor::Processor;
use wakuwaku::deps::sqlx::PgPool;
use wakuwaku::deps::tonic::{Request, Response, Status};

直接の依存が必要になる場合リンクをコピー

次の 2 つの場合は、それでも直接の依存が必要です。どちらの場合も wakuwaku が使うバージョンと互換性のあるバージョン指定にしてください。そうすれば Cargo がクレートを 1 つにまとめ、型も同一になります。

クレートをパスで参照する生成コードと derive マクロ。 tonic-prost-build が生成するコードは tonic、tonic_prost、prost を参照し、kanau の JSON 用 derive は ::kanau::... というパスに展開されます。これらは wakuwaku::deps 経由のパスでは解決できません。

[dependencies]
# tonic-prost-build が生成するコードが必要とします (クイックスタート参照)
tonic = "0.14"
tonic-prost = "0.14"
prost = "0.14"

# イベントやキャッシュの本体に付ける #[derive(JsonMessageSer, JsonMessageDe)] が必要とします
kanau = { version = "0.6", features = ["serde_json"] }
serde = { version = "1", features = ["derive"] }

[build-dependencies]
tonic-prost-build = "0.14"

メッセージ本体のシリアライズについては イベントの定義 で説明しています。

再エクスポートされたクレートの追加フィーチャー。 wakuwaku は sqlx と redis をデフォルトフィーチャーなしでビルドします。sqlx に入るのは Tokio ランタイムとデータベースドライバーだけ、redis に入るのは Tokio 用の接続とスクリプトのサポートだけで、どちらにも TLS は含まれません。フィーチャーを追加したい場合は、同じメジャーバージョンでそのクレートを追加し、必要なフィーチャーだけを指定します。Cargo はフィーチャーを、wakuwaku も使っている 1 つのクレートに統合します。

[dependencies]
wakuwaku = { version = "1.0.0-rc3", features = ["sqlx-pg", "redis"] }
sqlx = { version = "0.9", default-features = false, features = ["tls-rustls", "migrate", "uuid"] }
redis = { version = "1", default-features = false, features = ["tokio-rustls-comp"] }

このとき sqlx::PgPool と wakuwaku::deps::sqlx::PgPool は同じ型になります。

Tokio ランタイムリンクをコピー

wakuwaku は Tokio 上で動きます。cron ジョブ、イベントコンシューマー、gRPC サーバーは Tokio のタスクとして起動され、Tokio ランタイムの外で cron ジョブを開始すると panic します。wakuwaku 自身が Tokio の full フィーチャーを有効にしているので、features = ["full"] で tokio を追加しても余計なコストはかかりません。#[tokio::main]、#[tokio::test]、tokio::signal を使うために直接の依存が必要です。

インフラリンクをコピー

各フィーチャーは、自分で運用するサーバーに接続します。

詳しいセットアップは各フィーチャーのページで説明しています: イベント、sqlx、Redis、Meilisearch。

セットアップを確認するリンクをコピー

一度ビルドして、依存を取得・コンパイルします。

cargo build

一部の検査は、コードを完全にコンパイルしたときにだけ実行されます。たとえば間隔が 0 の cron ジョブは cargo check を通過し、cargo build で失敗します。CI では cargo build か cargo test を使ってください。