deno-redisのv1リリースに向けて
v1までにやりたいこと
新しいクライアントAPI
既存の多くのRedisクライアントライブラリは概ね以下のようなAPIを提供している code:javascript
client.get("foo");
client.set("foo", "bar");
クライアントオブジェクトの各メソッドがRedisコマンドに対応している この形式のAPIはわかりやすいものの、Redisに新しいコマンドが追加されていくと、クライアントがどんどん大きくなるという課題がある まだどういった形にするかは決まりきってはいないものの、以下のようなAPIをイメージしている
code:javascript
import { get } from "@redis/builder/commands/get.ts";
import { set } from "@redis/builder/commands/set.ts";
import { hgetall } from "@redis/builder/commands/hgetall.ts";
import { createClient } from "@redis/builder/createClient.ts";
const client = createClient({
port: 6379,
// フットプリントの削減などのために必要な機能だけを選択的に有効化したい
// ただ、セットアップの手間が増して使い勝手が悪くなる可能性もあるのがやや懸念
plugins: [
get,
set,
hgetall
]
});
await client.get("foo").toString();
{
const hash = await client.hgetall("hash").toMap();
assert(hash instanceof Map);
}
{
const hash = await client.getall("hash");
assert(isPlainObject(hash));
}
// @ts-expect-error @redis/builder/commands/del.tsが登録されていないため、delメソッドは未定義
client.del("foo");
背景・意図
ただし、既存のクライアント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のラッパ? (本体に入れなくてもよさそう)
ロック
ジョブシステム
ただし、本体に入れる必要はない