解決する課題に直面して初めてその技術が腹落ちする

はじめに

最近Webアプリケーション開発をしていて、使っている技術の存在理由が腹落ちする瞬間は、その技術が解決する課題に直面したときが多いことに気づきました。

例

SPA以外にSSGやSSRなどがある理由

現在の業務でフロントエンドとバックエンドを分けた開発をしており、フロントエンドはSPAで作っています。
ページがロードされる度にバックエンドのAPIを呼び出すように作ったところ、アクセス数が増加するとAPI呼び出し回数が増加し、DBへの接続試行回数が急増しました。
マスタデータの取得など、呼び出し結果が変わらないAPIも都度呼び出していました。
どう考えても非効率な実装であり、内容が変化しないデータを利用してページを表示したい場合はHTMLを事前にサーバー側でビルドしておくSSGの方が適しているなと感じました。

キャッシュが必要な理由

直面した課題は1つ目の例と同じで、API呼び出し回数が増加し、DBへの接続試行回数が急増したことです。
同じデータを取得するために何度もDBにアクセスするのは非効率であり、キャッシュを試してみたところDBへのアクセスが減りレスポンススピードが向上しました。
データの変更頻度を考慮してキャッシュの有効期限を設定することで、データの最新性を保ちつつDBへのアクセス回数を減らすこともできました。
キャッシュを利用するとメモリを消費するため、WebアプリケーションではなくWebサイトを作っているのであればSSGを利用するのが無駄なメモリ消費を抑えられてより良いとも思いました。

バックエンドとのやり取りする上でのTypeScriptの型のありがたさ

フロントエンドをJavaScriptで書いていると、バックエンドのAPIのレスポンスでどのようなデータが返ってくるのか分からず、その確認に時間がかかったりエラーが発生することが多くありました。
TypeScriptを使い始め、バックエンドのAPIのレスポンスの型を定義するようにしてみました。
すると型が一致していない場合はエラーが発生するため、原因の特定にかける時間が少なくなりました。

まとめ

本や記事を読んで技術を知ることも大事ですが、その技術を使ってみて初めて「こういうことか！」と腹落ちすることが多いです。 今後も実際に手を動かしながら技術を学んでいきたいです。