いいねボタンをアップデートしてみた
※本記事は広告を含みます
以前ブログにいいねボタンを実装してみたで導入したいいねボタンを最新化してみました。
なぜ最新化したのか
比較的雑なスタート
もともと、いいねボタンは個別の記事ページのみに配置する想定で実装していました。んで、いいね数を取得するのも、更新するのも個別のpost IDをパラメータする形となっており、まあパラメータ同じだったら、参照&更新を同一APIにしちゃっていいか！という組み方にしました。
一覧にも表示したくなる
しかし、結局あれこれやっているうちにTOPページなどにも記事ごとのいいね数を表示したくなってしまいました。この際、もともとのエンドポイントを利用しようとすると、記事数分のリクエストを投げなければいけなくなってしまい、結果無駄な通信が多く発生してしまうことになります。
パフォーマンス面の悪影響もそうですが、コスト的にもworkersの無料枠はリクエスト数に基づいて決まっているため、なるべく不要なリクエストが発生しないようにするべきです。
なので、今回この辺りをメンテナンスすることにしました。
修正方針について
まずは修正方針を検討していきます。一番の目的は「workers（API）へのリクエスト数を減らす」なので、ここを改善できるようにします。
APIの単位
今回メインで欲しいものは「複数のIDを受け付けてリストとしていいね数を返す」APIです。もともとのエンドポイントでこれには対応できないため、照会APIと更新APIをそれぞれ別のエンドポイントで作成していきます。
これをすると、「1リクエスト：1記事のいいね数」だったものが「1リクエスト：N記事のいいね数」になるため、これだけでもリクエスト数は大きく減らすことが可能です。
いいね数のキャッシュ化
APIを分割するだけでも効果は充分見込めますが、更にリクエスト数を下げるため、いいね数をキャッシュ化することにしました。ざっくりとした流れは
①いいね数取得時にキャッシュ
②いいね数更新時にキャッシュ更新
です。
基本的にはいいねを押す読者より、押さない読者の方が多いです。また、ページ回遊した際にも都度リクエストが走らないようになるため、かなりリクエスト数を減らすことができるはず。
実装イメージ
以下のようなイメージで実装を行っていきます。
なお、キャッシュはローカルストレージを利用することにしました。サーバー側でキャッシュするより効果は薄く、ほぼ回遊ユーザー用のキャッシュとなってはしまいますが、一定の効果はあると思います。
ちなみにサーバー側にキャッシュを持たせると、初回アクセスしたユーザーにもキャッシュが適用されるためより効率的な配信ができますが、今回のような更新が多い項目はキャッシュ管理が煩雑になりがちです。
更新が多いサーバーキャッシュをクライアントに追従させるメリットもあんまりなさそう（他ユーザーのいいね数更新を即時で拾う必要はない）ってのもありますし、ちょうどいい落としどころかなあと。
最後に
いいねボタンに関しては一旦これでいいかなあとおもった。
