Next.js App Router + microCMSなサイトをCloudflare Pagesへ

microCMSのコンテンツをNext.jsで表示させるアプリをCloudflare Pagesにデプロイした際にエラーが発生しました。cacheの設定はCloudflare Pagesでは利用できないため、環境変数を分岐させることで対応しました。さらに、NODE_ENVを使ってAPIキーの切り替えも可能です。このように、NEXT_RUNTIMEとNODE_ENVを使い分けることでCloudflare Pagesと開発環境での挙動を変えることができます。なお、next-on-cloudflareは便利なツールです。

microCMSのコンテンツをNext.js (App Router)で表示させたアプリを、Cloudflare Pagesにデプロイした時に遭遇したエラーへの対処方法覚書です。

`customRequestInit`（もといキャッシュ）の設定を環境によって変更する

2023/08時点では、cacheの設定がCloudflare Pagesにデプロイした場合は利用できない様子です。

14 Error: Network Error.
  Details: Error: The 'cache' field on 'RequestInitializerDict' is not implemented.

とはいえ「開発環境(next dev)ではno-cacheにしたい」と思うと、この設定は残したいところです。

対応: `NEXT_RUNTIME`環境変数を参照する

とりあえずの対応として、環境変数を使って分岐させてみました。

const customRequestInit: CustomRequestInit | undefined = (() => {
  if (process.env?.NEXT_RUNTIME === 'edge') return undefined
  return {
    cache: 'default'
  }
})();

process.env.NODE=ENVも使えますが、将来的に別SaaSに載せ替える時などを考えると、追加作業を少なくできる方に振りたいなと思います。

ちなみに、customRequestInitの値はno-cacheやdefaultでもエラーになりました。Cloudflare Pagesにデプロイする際は、undefinedにしましょう。

APIキーの「本番・テスト切り替え」などは、`NODE_ENV`でも可能

next devとビルド後アプリでAPIキーを差し替えたい場合などには、NODE_ENVも利用できます。

const customRequestInit: CustomRequestInit | undefined = (() => {
  if (process.env.NODE_ENV === 'development') {
    return {
      cache: 'no-cache'
    }
  }
  if (process.env?.NEXT_RUNTIME === 'edge') return undefined
  return {
    cache: 'default'
  }
})();

next-on-cloudflareがよしなにしてくれているのは、かなり助かります。

Cloudflare Pagesだけで挙動を変えたい場合は、NEXT_RUNTIME
next devとnext build後のアプリで挙動を変えたい場合は、NODE_ENV

という使い分けが、今のところしっくりきています。