Ph2の開発時に設計について検討したこと(ADR)

[yuizho]

Ph2の開発時に設計などについて一人で考えたこと、決めたことを背景含めて書き残す

• トピックごとにコメントに書いていく
• こちらのテンプレを参考に
  • https://github.com/joelparkerhenderson/architecture-decision-record/blob/main/templates/decision-record-template-by-michael-nygard/index.md

参考

• https://blog.studysapuri.jp/entry/architecture_decision_records

[yuizho]

別ユーザへのなりすまし対策

Status

• 作りながらこんなかんじが良さそうと頭の中で思い浮かべてるくらいのもの

Context

• ユーザのログインは不要で利用できるようにする
• AppSyncで実装可能な方法から考える
• 機密情報などはそもそも取り扱うような類のアプリではない

Decision

• 同室の別のユーザのIDは見えるので、他のユーザになりすまして何らかの操作ができてしまう (leaveとか叩いて、他のユーザを退出させたり)
  • openRoom, join時にuser_tokenを発行して、roomテーブルに登録しておく
  • pick, leave, kick, refreshTableなどの操作を行う際はuser_tokenをパラメータに渡して、user_idに紐づくuser_tokenと一致するかを確認するようにする
  • もちろん user_tokenはsubscriptionとかで他のユーザに渡らないようにする
• 退出済みのユーザが有効な user_token 渡してきた場合も認証エラーにしちゃう作りでよさそう
  • 退出済みのユーザがそのユーザとして操作するケースはない (部屋に入り直す場合は新たなユーザとして入るので)

Concern

• 特になし

Consequences

• https://github.com/yuizho/salon/pull/13

[yuizho]

Frontendのエラー監視について

Status

• 作りながらこんなかんじが良さそうと頭の中で思い浮かべてるくらいのもの

Context

• フロントエンド側で起きたエラーを監視したい
• Next.jsと組み合わせて使いやすいやすいやり方がよい
• 機密情報などはそもそも取り扱うような類のアプリではない

Decision

• Next.jsのに対応していて、エラーの管理(類似エラーはマージしたり、resolveとかステータス変えたり)もできて、環境ごとに集計もできるのでSentryを採用する
• Sentryだけである程度 perfomance の計測もできるのでしばらくSentryだけで様子見てみたい
• 環境の切り分けは、デプロイ環境ごとに environment の環境変数を分けて行う

Concern

• 無料の枠がどれくらいあるのかがあんまわかってない
• Transactionsのrateは10%くらいにしたけど、それでも枠に引っかかるようならもっとレートを下げるか0%にして、SentryのPerformanceの機能は全く使わない形にしちゃうのが良さそう

Consequences

• https://github.com/yuizho/salon/pull/15

[yuizho]

Frontendの本番 & テスト環境へのDeployについて

Status

• ある程度機能は実装できてきて、テスト環境とかデプロイ環境とかを整えて行きたい

Context

• Frontendの環境はVercelを採用する
  • BackendはAWSなのでそちらにまとめようかと思ったけど、ある程度無料で使えるのと、GitHubと連携したらmainとかにpushしたら勝手にデプロイしてくれるのが手軽なのでもうこれでいいかとなった
  • Frontendのサーバからバックエンドのリクエストはほとんど投げない想定なので、そこまでパフォーマンスに影響は出てこないと思ってる
• mainブランチにpushするとproduction環境にデプロイしてくれるのはいいとして、それ以外のブランチにpushするとpreview環境にデプロイされるのはちょっと問題がある
  • publicリポジトリなので、誰かがPRとか作るとそれもVercelにデプロイされちゃう
  • Vercel側の 制限 に引っかかる可能性がある
  • 悪意ある変更とかがテスト環境にデプロイされちゃうかも

Decision

• 直接pushできず、CODEOWNER(yuizho)のレビューを通らないとPRマージできないよう制限されたdevelopブランチを作る
• preview環境にデプロイされるブランチはdevelopブランチのみに制限する
  • https://zenn.dev/catnose99/articles/b37104fc7ef214
• 上記の制限によって、CODEOWNERのレビューを通ったもののみが、developブランチへマージされpreview環境へデプロイされる
  • もちろんproduction環境に対応したmainブランチも同様の制限がかかるようにしておく

Concern

• developブランチへ変更をマージ→preview環境でテストし→mainブランチへマージ という手順になるので少し煩雑にはなるし、運用に関する前提知識が必要

Consequences

• https://github.com/yuizho/salon/pull/17
• https://github.com/yuizho/salon/pull/19