キャッシュ
キャッシュ機能を提供するミドルウェア。
Cacheミドルウェアは、ResponseのStatusCode、Headers、Bodyに対してキャッシュ機能を提供します。すでにキャッシュされた内容については、次回リクエストを処理する際に、Cacheミドルウェアがメモリ内にキャッシュされた内容を直接クライアントに送信します。
注意:このプラグインは、BodyがResBody::StreamであるResponseをキャッシュしません。このタイプのResponseに適用された場合、Cacheはこれらのリクエストを処理せず、エラーも発生しません。
主な機能
-
CacheIssuerは、割り当てられたキャッシュキーの抽象化を提供します。RequestIssuerはその実装の一つで、リクエストのURLのどの部分とリクエストのMethodに基づいてキャッシュキーを生成するかを定義できます。独自のキャッシュキー生成ロジックを定義することも可能です。キャッシュキーは文字列型である必要はなく、Hash + Eq + Send + Sync + 'static制約を満たす任意の型をキーとして使用できます。 -
CacheStoreは、データの保存と取得操作を提供します。MokaStoreは、mokaをベースにした組み込みのメモリキャッシュ実装です。独自の実装方法を定義することもできます。 -
CacheはHandlerを実装した構造体で、内部にはskipperフィールドもあり、キャッシュが不要なリクエストをスキップするように指定できます。デフォルトでは、MethodSkipperを使用してMethod::GET以外のすべてのリクエストをスキップします。内部実装のサンプルコード:
他のフレームワークからの迅速な移行
以前に他のフレームワークのキャッシュメカニズムを使用したことがある場合、以下の概念マッピングがSalvoのキャッシュ実装への適応を助けます:
Rustフレームワーク移行ガイド
-
Actix-webからの移行: Actix-webの
actix-web-cacheなどのプラグインは通常個別に導入する必要がありますが、Salvoのキャッシュはコアライブラリの一部です。
他の言語フレームワーク移行ガイド
-
Go/Ginからの移行: Ginはミドルウェアパターンを使用しており、Salvoも同様のアプローチを採用しています:
-
Spring Bootからの移行: Spring Bootの宣言型キャッシュは、Salvoの明示的なミドルウェア設定に変換する必要があります:
-
Express.jsからの移行: Expressのキャッシュミドルウェアは概念的にSalvoと類似していますが、構文が異なります:
他のフレームワークから移行する際には、Salvoキャッシュのいくつかの重要な概念に注意する必要があります:
- キャッシュキー生成 -
CacheIssuerインターフェースで制御 - キャッシュストレージ -
CacheStoreインターフェースで実装 - キャッシュスキップロジック -
skipperメカニズムでカスタマイズ
デフォルトでは、SalvoはGETリクエストのみをキャッシュします。これは多くのフレームワークのデフォルト動作と一致しています。
サンプルコード