Cloudflare Workersの`wrangler deploy`と、Pagesの`wrangler pages deploy`の使い分け

Cloudflare側からは、Pagesに一本化したいお気持ちみたいなのを感じるけども。

wrangler deploy

Workersにデプロイするためのコマンド。

• 引数で指定したスクリプトか、wrangler.tomlに書かれたmainがエントリーポイント
• 指定されたソースから、自動でよしなにesbuildでビルドしてくれる
• Bindingsも自動で設定される

昔からある最も手軽なコマンドって感じで、コマンドを実行するたびに、上書きデプロイされる。--envで別のBindingsと区別してデプロイしたりもできる。

APIを作るだけならこれで必要十分だが、静的なアセットなどを返そうとすると、

• それすらAPIのルートとして実装し、KVやR2など別のストレージから取得して返す

というやや面倒なことをする必要があり、それをよしなにやってくれる、

• Workers Sitesという機能を使う

ことになるが、このWorkers Sitesはもはや注力されておらず、代わりにPagesを使ってねという感じになってる。

https://developers.cloudflare.com/workers/configuration/sites/

wrangler pages deploy

Pagesにデプロイするためのコマンド。

• ビルド済の成果物があるディレクトリがエントリーポイント
  • GitHubのリポジトリ連携でPagesを利用する場合と異なり、CIの機能はない
  • 自力でビルドする必要がある
• wrangler.tomlは読んでくれない
  • ややこしいのが、wrangler pages dev時は読んじゃうところ
  • https://github.com/cloudflare/workers-sdk/issues/3757
• Bindingsも設定されない
  • Dashboardから手動でポチポチ設定するしかない！

必要な一式のデプロイを、すべてCLIで完結できないところが特徴。

コマンドの引数に、branchを指定することで、リポジトリ連携と同じようにプレビュー用のURLを発行したりはできる。

とはいえ、がっつりバックエンド込みで開発する場合は、そこに紐づくBindingsも別で用意することになるだろうから、別のPagesアプリとしてデプロイするほうがわかりやすい気はする。

アセットなしのAPIをPagesにデプロイする場合は、

• Pages Functionsというファイルベースのお作法に沿って、functionsディレクトリ以下に実装する
  • https://developers.cloudflare.com/pages/platform/functions/
• 自分でビルドして_worker.jsというファイルにまとめる
  • https://developers.cloudflare.com/pages/platform/functions/advanced-mode/

という2パターンがある。

けど、wrangler pages deployによる直アップロード方式だと、CIがついてなくてfunctionsディレクトリはよしなに処理されないので、まあ後者が主なのでは。

各（メタ）フレームワークでCloudflareのアダプターを使った場合も、SSRのエントリーポイントが_worker.jsになる。

というわけで

• 静的なアセットをデプロイしたい
• 自動で永続的なプレビューURLがほしい
• そもそもリポジトリ連携で良い

という場合は、Pagesでいいけど、それ以外はまだまだWorkersって感じかな〜。

PagesがWorkersの上位互換になってるとは、正直まだまだ言い難いし。