GitHub認証を行う範囲が広すぎる

[hotate29]

現在の実装では、WebAPIへの全てのリクエストをGithubAuthenticationミドルウェアに通しています。

https://github.com/kenkoooo/AtCoderProblems/blob/ff203e2dc12fece1e5c85dfcbd92db7312313634/atcoder-problems-backend/src/server/mod.rs#L19-L41

このミドルウェアは、Cookieにtokenが含まれている時に動作するもので、GitHubのWebAPIにリクエストを送ることでtokenを検証しています。

https://github.com/kenkoooo/AtCoderProblems/blob/ff203e2dc12fece1e5c85dfcbd92db7312313634/atcoder-problems-backend/src/server/middleware/github_auth.rs#L123-L151

https://github.com/kenkoooo/AtCoderProblems/blob/ff203e2dc12fece1e5c85dfcbd92db7312313634/atcoder-problems-backend/src/server/middleware/github_auth.rs#L69-L81

この検証には結構時間がかかっているようで、ログイン時とそうでない時を比べると、大体250msの差があります。

URL	token	平均時間（範囲）
/atcoder-api/v3/user/ac_rank?user=hotate29	なし	107ms（89～135ms）
/atcoder-api/v3/user/ac_rank?user=hotate29	あり	361ms（306～440ms）
/atcoder-api/v3/user/rated_point_sum_rank?user=hotate29	なし	106ms（98～122ms）
/atcoder-api/v3/user/rated_point_sum_rank?user=hotate29	あり	361ms（309～505ms）
/internal-api/user/get	（当然）あり	363ms（299～409ms）

（hyperfineを使って、curlでリクエストを10回飛ばして計測しました）

/internal-apiに属しているエンドポイントにGithubTokenを提供するのが目的ですが、それを必要としない他のエンドポイントへのリクエストでも関係なく検証が行われるのでパフォーマンス的に問題かもしれません。

Lambdaの料金体系はよく知らない（ms単位の実行時間で課金されるらしい程度）のですが、これをどうにかしたら費用面が少し良くなるかも？と思いました。

どうにかする方策としては

• 各エンドポイントで検証を行う
• GitHubのAPIの使用をやめる
• internal-apiのスコープを作って、その中でGithubAuthenticationミドルウェアを使うようにする

といったものがあって、おそらく最後のものが無難かなあと思います。