ID:61606さん

# プロジェクト概要 - 自社サブスク事業のマイページ構築 - 5人程度の規模（要件定義&PM&インフラ：1人、フロントエンド開発：2人、バックエンド開発：2人） - 社内の基幹システムがマイクロサービスライクに存在しており、そこと通信してマイページの機能をユーザーに公開する - Jestによる単体試験を徹底しており、カバレッジ率は90%を超えていた # 役割 - フロントエンドエンジニア # 技術的課題と対策 - E2EテストをCIで回す仕組みの構築 - Playwright + GithubAction を使用 - はじめはテックリードからCypress + Amplify で構築するよう依頼された。が、デメリットもあったので、Playwright + GitHubActionの構成も含めてメリット・デメリットを整理して提案した - Amplify で E2EのCIを回すと、E2Eが落ちたときにデプロイできない、というデメリットがあった。GithubActionは柔軟に制御できた - Playwright は メインブラウザである Safari でのE2E試験が可能。Cypressは不可 - セキュアなVRT環境の構築 - テックリードが https://github.com/reg-viz/reg-suit の導入を検討していたが、これをそのまま使うとVRT結果(≒Storybookの内容) がpublicに公開されてしまう、というセキュリティ上の問題を抱えており、導入が見送られていた - S3からホスティングするサイトを、Cognitoで認証した自社のユーザーのみ閲覧できる仕組みを提案し、構築した - terraform化したこともあり、後に他プロジェクトでも流用された

# プロジェクト概要 - 大手時計メーカー会員制サイトのリプレイス - Laravel+WordPressのサイトをSPA化するため、バックエンドをAPI化しNext.jsを新規導入した - 5人程度の規模（要件定義&PM&：1人、インフラ：1人、フロントエンド開発：1.5人、バックエンド開発：2人） - フロントとバックエンドはすべて副業メンバー # 役割 - フリーランスとしてジョイン - 主な担当はフロントエンドで、開発環境構築、設計、実装を担当 - 他の副業メンバーへの指示出しや、バックエンド実装も担当 # 担当機能 - 会員登録 - 認証 - エラー共通処理 - 記事一覧、詳細表示 - TOP画面表示 # 技術的課題 ## 未ログインアクセス時の処理共通化 - 未ログインで会員限定ページにアクセスするときの処理が少し複雑だったのでカスタムフックを作って共通化した - 具体的には「未ログインで会員限定ページにアクセス → ログイン画面表示 → ログイン成功後に最初にアクセスした画面にリダイレクト」の処理を、各ページからuseAuthCheck({})を呼ぶだけで済むようにした ## Reactが検出したエラーをログに残す仕組みの実装 - sentryを導入するのが一番手っ取り早そうだが、プロジェクトの制約上導入できなかったので代替案を検討した - ReactがcomponentDidCatchでエラー検出したとき、バックエンドのログ記録APIを叩く方法を提案し、採用された。 - まれに本番環境でエラー発生していたが、ログから原因特定して修正することができた ## 動的なCSSの読み込みで発生する画面チラツキ対策 - 運用制約上、WordPressの管理画面からCSSファイルを登録し、登録したCSSをサイトへ適用する必要があった - バックエンドのAPIを叩いてCSSファイルのパスを取得し、動的にDOMに挿入する、という手段を用いて実装したところ、画面表示のチラツキが発生した - 原因は、動的なCSS適用される前のサイトが一瞬表示されてしまうことだったので、CSS適用前は画面表示を行わず(cssのvisibilityをhiddenにする)、DOM挿入してonloadが呼ばれたあとに画面表示する(cssのvisibilityをvisibleにする)という処理を追加した - 動的なCSS読み込みは useStyleLoad というカスタムフックで共通化した。 ## React Hook Formでバリデーション検出したとき、iPhoneのRadioButtonにFocusが当たらない問題対応 - React Hook Formにてバリデーションを検出すると、入力が不十分のinput要素にfocusが当たり画面スクロールされる動きになっている。 - ただし、iPhoneのRadioButton/CheckBoxはfocusが効かない仕様になっており、上記動作が動かない不具合が発生した - inputのラッパーコンポーネントとして\<Input\>コンポーネントを作成し、対象要素にfocusイベントが発生したとき かつ iPhoneの場合は、scrollIntoViewを実行して画面スクロールさせるようにして対処した - 詳細は こちら https://zenn.dev/daisuke7924/articles/5839e0094c5fdf を参照ください

# プロジェクト概要 - 物流会社の運送案件を管理するSaaSプロダクトの新規開発、保守 - Google CallenderライクなUIで、「誰が、いつ、どこに、何を運ぶか」を効率的に管理する - 5人程度の規模（要件定義&PM&インフラ：1人、フロントエンド開発：2人、バックエンド開発：2人） - フロントとバックエンドはすべて副業メンバー # 役割 - フリーランスとしてジョイン - 主にバックエンドの設計、実装を担当 - 最初は私の他にリーダーが１人いる体制だったが、3ヶ月でリーダーを引き継いだ - リーダーになってから、新規メンバーの募集面談の立ち会い、チームビルディング、コードレビュー、技術選定を行う # 担当機能 - graphQL Schema策定 - 認証 - エラー共通処理 - AndroidへのPush通知 - 運送案件の状態管理 (初期、未配、配車済、送信済、既読済、担当変更打診中、集荷開始、集荷完了) - 定期集荷機能 (決められた日付、曜日、時間帯に案件を作成する) - Excelデータのエクスポート、CSVデータのエクスポート、インポート # 技術的課題と対策 - ライブラリ内のコード読解や、技術選定と提案について書いております。 ## コード可読性を維持とDBクエリチューニングのバランス取り - やむなくTable間のRelationが複雑化したため、LaravelのRelationクラスを継承したCustomRelationを作成してコードをシンプル化したが、その際に、graphQLのQueryでSlowQueryが発生してしまった。 - eager loadするようCustomRelationの実装を工夫して、クエリが早くなるよう調整した。 - LaravelのGraphQLライブラリのLighthouseの機能拡張した。ドキュメントだけでは情報不足だったので、ライブラリ内のコード読解や、海外の技術Blogを読んで、Laravelやライブラリの理解を深める必要があった。 ## アクセス高負荷対策としてのDBレプリケーションの実装 - Read専用DBを複数用意してアクセス高付加対策を実施 - この際に、FrontからDB書き込み処理→DB読み込み処理が間髪入れずに行われると、古いデータを読み出してしまう問題が発生した - graphQLのカスタムディレクティブを実装し、query発行時にDB読み込み先を Primary/Read で切り替えられる共通処理を作成して解決した - LaravelのGraphQLライブラリであるLighthouseの機能拡張を行い実装 ## AndroidへのPush通知実現にむけた技術選定と提案 - AndroidへのPush通知が必要となり、PM兼インフラの方が最初の技術選定をしていただき、 「Laravel→AWS SNS→ FCM → Android」という流れで通知すると決められていた - 上記の実装を検証したところ、AWS SNS経由でFCMに通知するのに苦戦した - 私の方で調査＆検証したところ、AWS SNS経由せず、Laravelから直接FCMに通知するほうが簡単だとわかって、提案。採用された。 - 利用したライブラリ：https://github.com/kreait/firebase-php