perf2: 軽量な通知状態APIでプロジェクト画面の再取得を削減

[PocoPota]

概要

プロジェクト画面の初回ロードおよび定期更新で、フォーム・お知らせ・問い合わせの一覧APIが最大3本実行されていたため、画面表示とポーリング時の負荷が大きくなっていた。

このPRでは、未回答フォーム・未確認お知らせ・未読問い合わせコメントの有無を返す軽量な notification-status API を追加し、プロジェクト画面の初回ロード/60秒ポーリング/focus復帰時の更新を一覧再取得から状
態取得に置き換える。

課題

• /project の loader で複数の一覧APIを呼び、通知ドット表示のためだけに重いデータを取得していた
• 60秒ポーリングで router.invalidate() を実行しており、配下 loader がまとめて再実行されていた
• 既存の一覧取得APIには、カテゴリ指定等の配信対象 delivery を読み取り時に補完する副作用があった

解決策

• GET /project/:projectId/notification-status を追加
• フロントの通知ドット更新を notification-status に集約
• ポーリング/focus復帰時の router.invalidate() を廃止
• 読み取りAPIにあった delivery 補完の責務を、以下のタイミングへ移設
  • 配信承認時
  • 企画作成時
  • 企画の種別/場所更新時
• delivery 対象解決・作成処理を project-delivery-targets に集約し、内部通知同期処理からも再利用

実装上の整理

• 既存の内部通知同期処理にあった delivery 対象解決・delivery 作成ロジックを project-delivery-targets に集約
• internal-notification は配信時刻到達後の通知送信、claim、失敗時の再試行制御に責務を絞った
• 承認時・企画作成時・企画属性更新時・通知同期時で、カテゴリ指定/個別指定の delivery 作成ルールが分散しないようにした

仕様上の注意

• 一度作成された delivery は、後から企画の種別/場所が変わって対象外になっても削除しない
• 配信予定日後に新しい企画が作成された場合や、企画情報変更で対象条件に合うようになった場合も delivery を作成する
• 読み取りAPIは副作用を持たない方向に寄せる