Node.jsの役割（p54）

2つの役割

フロントエンドの開発環境を構築する
サーバーとして利用する

フロントエンド

JavaScriptの拡張言語のTypeScriptやCSSの拡張言語のSassなどはそのままではブラウザ上で利用できない為、ブラウザが解釈可能なJavaScriptやCSSへ変換する必要がある。こうした変換作業の過程でNode.jsが用いられている。
Node.jsにはnpmと呼ばれるパッケージマネージャーが含まれている。npmを使うことでプロジェクト内のライブラリを一元管理することができる

サーバーとしてのNode.js

クライアントからのリクエストに対してレスポンス返す役割を実現可能

ブラウザのJavaScriptとNode.jsのJavaScriptの違い

ブラウザのJavaScriptでは、DOMを操作できる
Node.jsのJavaScriptでは、ファイルを操作できる

やまやま

Web API（p186）

Web APIとは

サーバーが持っている機能やサービスをWebを通じて外から使えるようにしたもの

Web APIの利用シーン

外部のサービスを利用するケース
フロントエンドとバックエンドの接点（インターフェース）として利用するケース
- 例：在庫管理を行う社内システムを作る場合、サーバーが在庫の検索や入庫、引き当てといった機能をWeb APIとして提供し、フロントエンドではこのAPIを呼び出して画面の表示や更新を行う

Web APIの種類

REST API
GraphQL
- APIのエンドポイントは１つだけで、代わりに必要なデータや行いたい操作を記述した「クエリ」をリクエストとして送信する。
tRPC
- RPC(Remote Proceduce Call: 遠隔手続き呼び出し)とは、離れた場所にあるコンピュータの処理を呼び出す方法を定めたもの
- tRPCはフロントエンドと親和性の高い技術で、フロントエンドとサーバーサイドの両方にTypeScriptを使用する。TypeScriptの型を通じてAPIの定義を自動的に連携することで、型のチェックやエディタでの入力保管ができるようになる。

Web APIを使うための技術

fetch API
- WebページからWeb APIを呼び出す一番基本の方法。ブラウザの標準機能なのでインストールなどの準備は不要。
Axios
- Web APIの呼び出しを標準のfetchよりも簡単、便利に扱えるライブラリ。
- fetchとの違い
  - 共通の設定をまとめて扱える
    - APIサーバーのベースURLや、リクエストヘッダーにセットする認証情報など、共通の設定をまとめて書くことができる
  - エラー処理が扱いやすい、カスタマイズできる
    - 400番台、500番台のステータスコードをfetchではエラーとして扱わない（fetchが責任を持つ通信自体は問題なく完了しているため）ので、実装者がレスポンスの内容（ステータスコード）を見て実装する必要があった。
    - Axiosでは400、500番台のステータスコードがデフォルトでJavaScriptの実行時エラーになるので、標準のtry〜catch文でエラーを処理できる。
  - リクエストやレスポンスに共通処理を挟むことができる
    - interceptorsを使って、リクエストやレスポンスに共通する処理を追加できる。例：「すべてのリクエストのログを記録する」「レスポンスでエラーが返ってきた時にエラーメッセージを表示する」など
      参考：インターセプター

やまやま

MPAとSPA（p204）

MPA（マルチページアプリケーション）

ページが切り替わるごとにサーバーと通信してHTMLを取得する形式

SPA（シングルページアプリケーション）

ユーザー操作によって画面内容が変化しても、URLは変化せず、１つのURLでさまざまな画面状態が表現される

SPA + ルーティングによるページ遷移

HTMLにはプッシュステートと呼ばれるURLを書き換える機能があり、JavaScriptから利用できる。このプッシュステートを応用したルーティング機能をReactやVue.jsに導入し、動的なUIの書き換えとURLの変更を行うことで擬似的なページ遷移を再現する。
ルーティング機能を提供する代表的なライブラリにはReact RouterやVue Routerがある。Next.js（Reactのフレームワーク）やNuxt.js（Vue.jsのフレームワーク）にはこのルーティング機能が含まれている。

やまやま

レンダリング方式（CSR/SSR/SSG/ISR）（p208）

※レンダリングという用語の意味合いの違いについて

JavaScriptのフレームワークにおける「レンダリング」：HTMLを出力すること
ブラウザにおける「レンダリング」：DOMやCSSの状態をもとに、画面の描画結果を得ること

各レンダリング方式について

CSR（クライアントサイドレンダリング）
ユーザーのブラウザ（クライアント）のJavaScriptで動的にHTMLを出力する方式。純粋なReactやVue.jsによるSPAはこの方式。後述のサーバーサイドレンダリングなどと比較して構成がシンプル。一方で利用者のブラウザ設定でJavaScriptが無効になっている場合にページが正しく表示されないこと、ページごとのOGP設定ができないなどのデメリットもある。
SSR（サーバーサイドレンダリング）
クライアントサイドレンダリングの初期レンダリングの問題を解決するためにサーバーサイドで行うようにしたもの。クライアント側で初期レンダリングを行わないので、初期読み込みの時間短縮やSEO的な問題も解決される。
サーバーサイドレンダリングを行うことで、ページタイトルやOGP（Open Graph Protocol）で設定したSNS共有用のシェア画像などを細かく設定可能。SEO上のメリットも得られる。
サーバー環境としてNode.jsが必要。レンタルサーバーと呼ばれるサービスはNode.jsが使用できないことが多く、各種プラットフォームを提供するクラウドサービス（Paas：Platform as a Service）を利用することが一般的。
※代表的なPaasにはAWS、Google Cloud、Heroku、Vercelなど
SSG（静的サイトジェネレータ）
あらかじめHTMLを生成しておくことで、クライアントサイドでもサーバーサイドでもJavaScriptによる初期レンダリングを行わない方式。（※厳密にはレンダリング方式ではない）
ISR（インクリメンタル静的再生成）
サーバーサイドレンダリングと静的サイトジェネレータを掛け合わせたような手法。