📘

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

1 min read

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

前提

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

最初にぶつかる壁

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

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

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

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

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

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

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

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

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

Discussion

ログインするとコメントできます