Fantiaでよく見られている画面といえば、もちろん各クリエイターさんの投稿画面ですが、

通知の一覧画面もかなりの頻度で見られています。

通知画面はこちら（ログインが必要です）

この通知は以下の場合などで送られます

・プランに加入した時

・加入しているクリエイターさんが投稿をした時

・などなど….

多岐に渡るタイミングで送られておりその数は膨大です。

そして、その膨大な数の通知が送られるのは、ひとりのユーザーにおいても当てはまり、

多くのファンクラブに加入すればするほど数が増えてゆきます。

そしてある時、一部のユーザーにおいて通知一覧画面の読み込みが極端に遅くなるという事象が発生していることが判明したのです。

原因はkaminariを使ったページャー部分でした。

とは言ってもkaminariが悪いわけではなく、大量のデータとページャーの相性が良くなかったのです。

※kaminari

簡易にページャを作れるGemライブラリ

https://github.com/kaminari/kaminari

※ページャー

以下画像のようなページ送りのUI

ページャーのUIを生成するにあたり、必要になってくるのは対象となるデータの数です。

とりわけ、上図のようなページャーは最深部への遷移が存在するため、

最大何件のデータがあるのかを取得しなければいけません。

一般的な量であれば最大件数の取得で処理は遅くならないのですが、あまりにも数が多い場合は最大件数を取得するだけで処理が遅くなります。

実際に件数の取得を行なっている箇所は以下です。kaminariのライブラリ内でCOUNTを行うクエリが実行されます。

COUNTを実行するソース

対処方法としては大規模データを扱うに最適化したページ構成にするしかありません。

最大件数の取得を行わず、表示させたいデータだけを取得する必要がありました。

より近代的なUIとしてはTwitterのように、スクロールして読み込んでいくタイプがあげられます。

我々としてもゆくゆくはそのようなUIにしていきたいのですが、当時発生していた遅延に対しては最速で改善しなければいけません。

しかしページャーを消すわけにはいかず、代わりとなるようなものを自身で実装するかどうかで悩みました。

そんな中、調べてみるとこの問題の対策としての機能がkaminariに存在するという記事がいくつか見られました。

『Paginating Without Issuing SELECT COUNT Query』

githubのReadmeにも書かれている『without_count』は、最大件数の取得を行わず、簡易的なページャーUIを実現するためのオプションです。

『次のページへ進む』と『前のページに戻る』のボタンしかないUIですが、通知画面の用途であれば十分なのでこのオプションを使うことにしました。

しかし、当時使っていたkaminariのバージョンが古く、アップデートが必要でした。

UIを独自実装するか、バージョンアップしてwithout_countオプションを使うかを考えた結果、

kaminariを使う以上はその枠組みの中で実装した方が良いと考えアップデートすることを選びました。

そうしてkaminariをアップデートしUIを変更した結果、通知一覧画面の表示を早くすることに成功したのです。

図で度々使われている女の子の素材は弊社の公式サイト「とらラボ」で無料配布されています。

スライド等のプレゼン資料や技術書の作成など、商用問わず全て無料で使えるので、ご覧ください。

https://yumenosora.co.jp/tora-lab/special

現在Fantiaはサービスに規模に対しての開発エンジニアは人手が不足しており、積極的にエンジニアを募集しています。

繰り返しとなりますが、「Fantiaを一緒に改善したい！」と思うエンジニアの方はぜひご応募ください。

※Fantiaエンジニアの採用情報はこちら