Next.jsキャッシュ戦略はこんな感じで行こうと思う

Next.js セカンドインプレッション - koudenpaのブログで、書いた通りNext.jsとはしっかり付き合いはじめて日が浅いのだけれど、横目で眺めていた時期と主体的に触って感じたことからどういう構成をとるのかの考えが固まってきたので書いておく。

暫くたって見直して「とんちんかんなことを考えていたな」となるのも一興。

なお、「こんな感じで行こう」の対象は本業ではなくプライベートです。

考え方

この辺は当たり前のことではあるけれど、目的を見失わないように何を考えてキャッシュするのかは考えておきたい。

Amazonのような大手でも（大手だからこそか？）キャッシュの構成ミスで他人の情報を応答してしまうようなことがある。そのくらいキャッシュは難しい。そうした不測の出来事を避けつつ、キャッシュする利点を得られる落としどころを考えたい。

SSRと静的ファイルは全て強くキャッシュする
- ここにはセッションに依存した内容は含めない
- 認証ヘッダやCookieはCDNで落とす
  - これによってセッションを参照するリスクを無くす
APIリスエストはキャッシュしない
- セッションに依存する内容は全てこちらに寄せる

ユーザー固有の情報のキャッシュは諦める形。

Serverless Next.js Component を使わせてもらおうと考えている。

Next.jsは別にLambda@Edgeではない普通のLambdaでいい*1のだけれど、どうやらNext.js界隈はVercelを見習ってエッジで処理したい思いが強いように感じる。

まぁまぁシンプルで実際的な構成になったのではないか。

雑に検索するとどうやってキャッシュコントロールするのかは分かるのだけれど、どう構成するのがいいのかはあんまり出てこない気がする。検索の仕方が悪いだけなんだろうか。

ともあれ、テキストに起こして作図したらすっきりしたので、後はこれをベースに構成して課題が出てきたら都度潰そうかと思う。

*1:制限も緩いし