キャッシュ機能を提供するミドルウェア。
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のキャッシュ実装に適応するのに役立ちます:
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リクエストのみをキャッシュし、これは多くのフレームワークのデフォルト動作と一致します。
サンプルコード