_

Results 5 comments of _

今回プラグインを公開した際に同様の問題に出くわしたので、修正したいと思います。

@futchitwo すいません... 解決しましたがPRに`Closes`をつけるのを忘れてしまったのでcloseしてもらえますか?

別途でusers/relations を呼び出すのであれば、userEntityServiceのpack段階で行われるgetRelationの情報を元にフォロー状態を取得させて、userLiteに新たにfollowStateのようなenumを定義して追加してあげれば現状とそこまで動作的には変わらない気がしますね。

そこら辺の負荷についてmisskey上のコードを見ていたんですが、 結論から言うと私が調べた限りでは、ユーザー取得時のRelationの参照は最終的にはすべてローカル上でのみ行われており、cacheから取ってきていなく、データベースから直接参照されています。 https://github.com/misskey-dev/misskey/blob/c530a46e547791b22ecf12fe1b9e952f7df0a58c/packages/backend/src/core/entities/UserEntityService.ts#L180 なので増えるとしても取得時に毎回クエリが打たれる処理くらいだと思っています(**それでもioレベル、ましては中堅でもえげつない処理だと思われ**)。 ※連合側のフォロー・フォロワー情報の処理はapのinbox側でいい感じに行われているっぽい感じがしたので省きました。 可能性があるとするならばcacheServiceにいい感じにfollowingsCacheが存在しているのでこれをfollowersCacheとかでいい感じに出来たりしないかなってことですかね... https://github.com/misskey-dev/misskey/blob/c530a46e547791b22ecf12fe1b9e952f7df0a58c/packages/backend/src/core/CacheService.ts#L104 > (キャッシュがあるとはいえ、追加情報をそれなりに取るので) まさにこれなんですよね

Twitter(X)みたいに「n件の新しいツイート」の件数だけを返すのと、新しい通知があればtrue返すみたいなapiがあれば出来そうだと思った(現状がここらへんをwebsocketを使用してるため)