💻 Webサイト開発
■開発概要 - フロントエンドは、Next.js, TypeScriptを利用して画面を構築。 - バックエンドで主にロジックをかき、Rest APIを利用してフロントにデータを渡す。 -UT, E2E(Jest, Cypress, storybook) - インフラはAWSを利用。 こんな感じです。僕はフロントを担当しているので、画面周りのスタイリングとコンポーネント作成をしていました。振り返ってみると、環境がらみのエラーの解決に苦労していたなぁと思いました。 ■苦労と解決策 ◯ 謎のCORSのエラー まずひとつ目は謎のCORSエラーです。ブラウザでAPIコールした時に発生しました。各所担当するエンジニアの方にバックエンド、インフラ側、ともに設定をしてもらったのに、なぜかエラーが出続けていました。 「何もわからん。。。」 データの流れを追いながら、どこが原因になっているのか全くわかりませんでした。 結局、原因がわからず時間が経過していきました。 解決のひとつのきっかけは、プロジェクトマネージャーの一言です。 あるとき、プロジェクトマネージャーが別プロジェクトのチャットで、障害対応について方針を伝えていました。 障害の対応は以下の順に行う ・原因究明ではなく、バケツの穴を塞ぐ。 ・原因究明 ・原因に対する正規のソリューションで対応する。 これでいきましょー! と言っていました。 これを見て、 自分のプロジェクトでも障害とはいえないまでも、エラーが原因で開発が進められない状態だったので、このフローで対応する必要があると思いました。 以前までは、「原因は何だろうか??」とずっと原因究明ばかり行なっており、解決に至っていませんでした。しかし、このマネージャーの一言で、「とりあえずバケツの穴を塞ぐことを考えてみよう!」と思うようになり、方針が変えました。 バケツの穴をどう塞ごうかなー CORSエラーはブラウザでAPIコールすると発生するので、「サーバー側でAPI叩けばいいのでは?」と思い、その方針で試みることにしました。 ブラウザでAPIコール ではなく、 ブラウザではAPI Routesのエンドポイントをコール —> API Routes で正規のAPIをコール これで、CORSエラーは発生せず、意図通りの挙動になりました。 とりあえず、バケツの穴を塞ぎ、開発を前に進めることができました。 このあと、原因究明をしたのですが、結局わかりませんでした。 正直、消化しきれない部分もありますが、開発を前に進められたのは非常に良かったです。 ◯ 初期表示のパフォーマンス改善 APIの繋ぎこみが概ね終わったあと、ページを開いてみると、 「お、お、遅い。。。」 初期表示が非常に遅いことがわかりました。 1ページで利用するデータとコンポーネント数が多いことが原因です。バック側、フロント側の双方にパフォーマンスの改善が課題になりました。 この解決策は完全に偶然でした。 React 18の機能の「lazy()」メソッドを調べている時に「遅延コンポーネント」の存在を知りました。 へー、そんなのあるんだー と思い、調べてみると、「交差オブザーバー」なるもので実現できることがわかりました。 https://developer.mozilla.org/ja/docs/Web/API/Intersection_Observer_API これを利用して、Next/Imageのようにビューポートに入った場合、コンポーネントをレンダリングするような仕組みを実現しました。 画像の遅延処理同様に、初期表示のコストが下がり、フロントのパフォーマンスが改善されました。 初期表示の改善方法は他にもありそうなので、読者の方から教えていただきたいと思っています〜 ◯ 環境差異のエラー解決 これ系のエラーがホントにやめてほしいです。。。 ローカルでは全く問題ないのに、テスト環境にあげた途端、503エラーが吐かれました。 サーバーログをぱっと見ても全然わからず、手詰まりでした。 ここでふと思ったのは、 「そもそもNext.jsのSSRを利用したアプリケーションをAWS Amplifyにデプロイしたとき、サーバーサイドの処理はどこで行なっているんだろう??」 このあたりの仕組みがイマイチわかっていませんでした。 ログを確認しようにも、どのサーバーにログが吐かれるのかもわからないのに確認のしようがないですね。。。 ということで、Amplify大先生の仕組みを調査を行うことが第一だと思い、リサーチをしました。 するとAmplify にSSRまたはISRのアプリケーションをデプロイすると、以下のようなLambdaが作成されるようです。 * * Default Lambda@Edge for Next CloudFront distribution * API Lambda@Edge for Next CloudFront distribution * Image Lambda@Edge for Next CloudFront distribution * Next.js Regeneration Lambda https://zenn.dev/laiso/articles/8c619c38bd7b7b Lambda@Edgeが作成されるんですね!それまで全然知りませんでした! これらのキーワードとリソースネーム(ARN)を元にそれらしきLamdaとログを発見できました。 結局原因は、ローカルで利用しているNodo.jsのバージョンとLambdaのランタイムのバージョンに差があり、利用できない組み込みメソッドが存在することでした。 今振り返ると、これはログの確認ができないと絶対発見できなかっただろうなーと思いました。 エラーから学ぶと言うのはホントのことですね!AWS周りの勉強にもなりましたし、むしろプラスでした。