# 求職者検索機能の開発
## 概要
- スカウトサービスにおける法人ユーザー用の求職者検索機能のバックエンドおよびフロントエンドの開発
## 担当
- バックエンドおよびフロントエンドエンジニアのメンバーとして開発を担当
## 使用技術
- GraphQL
- BE
- Nest.js
- TypeORM
- FE
- Next.js
- React Hook Form
- Chakra UI
## 課題
- サービス自体が立ち上げ直後ということもあり、法人ユーザーがスカウトしたい求職者を条件検索する機能がなかった
- 地域検索などの検索条件が複数ありUIも複雑だったため、フロントエンド、バックエンドともにパフォーマンスに懸念があった
## 取り組み
- 当初の要件では検索条件をモーダル表示し、求職者の地域検索は「モーダル内で都道府県選択→市区町村選択と画面遷移する」というReactでは実装難易度が高いものだった。そのため、PMと仕様相談し「1ページ目で都道府県選択→2ページ目で市区町村含むその他の検索条件選択」とすることで、UXを損なわずに実装難易度を下げるように仕様を調整した。
- 複数の検索条件を選択するページで大量のチェックボックスが並んでいることで、フロントエンドのパフォーマンスに懸念があった。そのため、チェックボックスをグループ化しそれぞれのコンポーネントをメモ化することで、検索条件選択時のレンダリングを最適化しUXを向上した。
- バックエンドの実装において、複数条件による検索を行うのでパフォーマンスに懸念があった。そのため、検索条件によってouter joinとinner joinを使い分ける、一度のテーブルjoinですべての情報を取得せずに適度にSQLを分割して発行する、インデックスを見直すなどして、APIのパフォーマンスを向上した。
# CIの改善
## 概要
- Github actionsにおけるCIの改善
## 担当
- バックエンドおよびフロントエンドエンジニアのメンバーとして開発を担当
## 使用技術
- Github, Docker, Cypress
## 課題
- フロントエンドのCIにおいて、Next.jsのビルドチェックにGraphQLの型情報ファイルが必要だったが、このファイルはバックエンドが起動されていないと作成できなかった。そのため、CIではAWS上の開発環境にあるバックエンドの資源をもとにファイル作成しており、pushされたバックエンド資材にインターフェースの破壊的な変更があるとCIが落ちてしまっていた。
- フロントエンドとバックエンドの両方を触れるエンジニアがチームにいなかったため、この状態を改善できるメンバーがいなかった
## 取り組み
- CI上のDockerでバックエンドの資材をビルドし、それに対してフロントエンドからGraphQL introspectionにより型情報ファイルを作成することで、pushしたバックエンドに破壊的変更があっても正常にCIが通るように改善した
- バックエンドのビルドに際しては、node_modulesをキャッシュ化することでCIの実行時間を短縮することで、作業効率の向上とGithubへの課金額減少に貢献した。