こんにちは！りょた(@Ryo54388667)といいます(^o^)
今回は本プロジェクトが一段落するので、その振り返りについて書いていきます。
- 他人の反省を知りたい人
- つまづく部分を知っておきたい人
こんな人に読んでいただけると幸いです！
開発概要
まず、さらっと開発の概要についてお伝えします。
- フロントエンドは、Next.js, TypeScriptを利用して画面を構築。
- バックエンドで主にロジックをかき、Rest APIを利用してフロントにデータを渡す。
- インフラはAWSを利用。
こんな感じです。僕はフロントを担当しているので、画面周りのスタイリングとコンポーネント作成をしていました。振り返ってみると、環境がらみのエラーの解決に苦労していたなぁと思いました。
苦労と解決策
謎のCORSのエラー
まずひとつ目は謎のCORSエラーです。ブラウザでAPIコールした時に発生しました。各所担当するエンジニアの方にバックエンド、インフラ側、ともに設定をしてもらったのに、なぜかエラーが出続けていました。
「何もわからん。。。」
データの流れを追っていましたが、どこが原因になっているのか全くわかりませんでした。
結局、原因がわからず時間が経過していきました。
解決のひとつのきっかけは、プロジェクトマネージャーの一言です。
あるとき、プロジェクトマネージャーが別プロジェクトのチャットで、障害対応について方針を伝えていました。
障害の対応は以下の順に行う
- 原因究明ではなく、バケツの穴を塞ぐ。
- 原因究明
- 原因に対する正規のソリューションで対応する。
これでいきましょー！
と言っていました。
これを見て、
自分のプロジェクトでも障害とはいえないまでも、エラーが原因で開発が進められない状態だったので、このフローで対応する必要があると思いました。
以前までは、「原因は何だろうか？？」とずっと原因究明ばかり行なっており、解決に至っていませんでした。しかし、このマネージャーの一言で、「とりあえずバケツの穴を塞ぐことを考えてみよう！」と思うようになり、方針を変えました。
「バケツの穴をどう塞ごうかなー」
CORSエラーはブラウザでAPIコールすると発生するので、「サーバー側でAPI叩けばいいのでは？」と思い、その方針で試みることにしました。
ブラウザでAPIコールではなく、ブラウザではAPI Routesのエンドポイントをコール —> API Routes で正規のAPIをコール。
これで、CORSエラーは発生せず、意図通りの挙動になりました。
とりあえず、バケツの穴を塞ぎ、開発を前に進めることができました。
このあと、原因究明をしたのですが、結局わかりませんでした。
正直、消化しきれない部分もありますが、開発を前に進められたのは非常に良かったです。
初期表示のパフォーマンス改善
APIの繋ぎこみが概ね終わったあと、ページを開いてみると、
「お、お、遅い。。。」
初期表示が非常に遅いことがわかりました。
1ページで利用するデータとコンポーネント数が多いことが原因です。バック側、フロント側の双方にパフォーマンスの改善が課題になりました。
この解決策は完全に偶然でした。
React 18の機能の「lazy()」メソッドを調べている時に「遅延コンポーネント」の存在を知りました。
へー、そんなのあるんだー
と思い、調べてみると、「交差オブザーバー」なるもので実現できることがわかりました。
これを利用して、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
Lambda@Edgeが作成されるんですね！それまで全然知りませんでした！
これらのキーワードとリソースネーム(ARN)を元にそれらしきLamdaとログを発見できました。
結局原因は、ローカルで利用しているNodo.jsのバージョンとLambdaのランタイムのバージョンに差があり、利用できない組み込みメソッドが存在することでした。
今振り返ると、これはログの確認ができないと絶対発見できなかっただろうなーと思いました。
エラーから学ぶと言うのはホントのことですね！AWS周りの勉強にもなりましたし、むしろプラスでした。
今後の課題
コードレビューをして、双方の意見に甲乙つけ難い場合、どちらを採用するのか？これが最も大きな課題かなと思っています。
現在、僕を含めジュニアのエンジニアでフロント部分を作成しているのですが、ちょくちょくディスカッションで詰まる時があります。どの方法もメリットとデメリットがあり、決め手に欠けるケースです。
これみなさん、どうしてるのでしょうか？
CTOやテックリードの人がいれば、意見を求めることもひとつの方法だと思います。僕のチームには、現在そういった役職の人がいません。この場合の対応をどうするかが、課題だなーと思っています。
現在、採用を考えているのは、「機械的に順に採用していく」ということです。
例えば、「双方の意見に甲乙つけ難いので、今回はAさんの意見、次に同じケースになったら、Bさんの意見を採用する」というような形式です。
うちではこうしているよー！とか事例があれば教えてください！
最後に
振り返っていると、楽しくなってたくさん書いてしまいました。
新しいプロジェクトも今月から始まりそうな気配がするので、楽しみです！今年もゴリゴリ開発していきます！
最後まで読んでいただき、ありがとうございます！
フロントまわりの技術記事も書いていますので、興味のある方はこちらも合わせて見てみください〜