リスト取得ロジックの設計

リソースのリストを取得する際の設計について考察する。
（投稿のタイムラインや、ユーザー検索をどうやって設計するか、というお話）

前提

• ソート（並び替え）したい
  • 例） EDACB→ABCDE
• フィルター（絞り込み）したい
  • 例） ABCDE→ACE
• リストのサイズは時間の経過とともに大きくなっていく
  • 例） ABCDE→ABCDEFG→ABCDEFGHI...
  • ユーザー数や投稿数が増えていくイメージ

最初にぶつかる壁

リストサイズの肥大化に伴い、APIリクエストから画面描画までの時間が長くなり、UXの低下を招く。

• ソートに時間がかかる
• フィルターに時間がかかる
• レスポンスサイズが大きくなり通信時間が長くなる
• クライアント側でのレンダリングに時間がかかる

そこで、部分取得対応を入れるという話になる。
（いわゆるページングと言われているものなのかな。ソート時間は解決できないけど。）

この時、各ページの取得タイミングによってはソート・フィルターの変数の値が前回と変わり、リソースの欠損や重複が発生してしまう可能性がある。これは避けたい。

どうやってリソースの欠損・重複を防ぐ？

初回（1ページ目）のリクエスト時に、全てのリソースに対してソート＆フィルター済みのID配列を返す（リソース自体は1ページ目分だけ）。2ページ目以降はクライアント側で2ページ目のID配列を計算して、ID指定のリソース取得APIリクエストを送信する（ID指定なのでソートもフィルターも行われないので速い）。

これにて一見落着かと思いきや、もちろんそんな事はなくて、「全てのリソースに対するソート＆フィルター」の処理がスケールしない。

ここからの対応はそのリストの要件次第なのだが、大きく次の2つに分けられるかと思う。
A. 最新のリソースが対象となっていれば十分（タイムラインの投稿等）
B. 全部のリソースを対象としたい（ユーザー検索等）

※一旦時間が来たので続きはまた今後。YOUTRUSTでは上記A、Bをどのように設計しているかを書こうかと思う。