deno-redisのv1リリースに向けて
v1までにやりたいこと
新しいクライアントAPI
既存の多くのRedisクライアントライブラリは概ね以下のようなAPIを提供している code:javascript
client.get("foo");
client.set("foo", "bar");
クライアントオブジェクトの各メソッドがRedisコマンドに対応している この形式のAPIはわかりやすいものの、Redisに新しいコマンドが追加されていくと、クライアントがどんどん大きくなるという課題がある まだどういった形にするかは決まりきってはいないものの、以下のようなAPIをイメージしている
code:javascript
import { createClient } from "@redis/builder/createClient.ts";
const client = createClient({
port: 6379,
});
// * コマンドごとにメソッドを用意するのではなく、単一のAPI経由でコマンドを実行する
// * 各コマンドごとにオーバーロードを定義し、ミスを防止できるようにする (型定義であればフットプリントの増加は防げるはず)
await client.command("GET", "foo");
await client.command("SET", "foo", 1);
背景・意図
ただし、既存のクライアントAPIも削除せずに引き続き提供は続けたい
Redis Clusterクライアントの実装 (#220) まだ最低限の状態しかないので、色々充実させていきたい
全ノードへのコマンドのブロードキャスト
コネクションプーリングの実装
最低限必要な機能だと思うので優先度は高め
CommandExecutor.connectionを削除したい
Connectionは将来的に変更する可能性が高いので、v1時点では内部APIにとどめておきたい
そうすると、CommandExecutorにisClosedとかをもたせることになりそうだけど、若干の違和感を感じなくもない...😭
Pipeline周りのAPIの見直し (#223/259)
Monitorコマンドの実装 (#183)
RESP3サポート
Redis Sentinel
Pub/Sub APIをWeb Streams APIベースにする
既存のsubscribe()はAsyncIteratorベースにして、新しくsubscribeStream()みたいなメソッドを追加すべき？
Shared pub/sub
Redis v7.0でサポートされた機能
その他の案
ロギング
go-redisとかはHookを提供して、コマンドの実行前後に追加処理を行えるようにしてる クライアントの自動生成
将来
Client side cachingのラッパ? (本体に入れなくてもよさそう)
ロック
ジョブシステム
ただし、本体に入れる必要はない