お問い合わせフォームのAPIを実装して、いつも通りデプロイしたらビルドは通る。でもURLを開くと真っ白、というか404。あー、これ絶対何かやらかしたな、と思いながら何度もリロードしてました。
そもそもなぜサーバーサイドが要るのか
お問い合わせフォームって、送信ボタンを押したらSMTP経由でメールを飛ばしたいだけです。素朴に考えると「クライアントのJSだけで完結させられないの?」って一瞬思うんですよね。
でも実際には無理で、理由は2つあります。
一つは、SMTPのユーザー名・パスワードをどこかに書かないといけないこと。ブラウザに配信されるJSに書いてしまったら最後、誰でも開発者ツールで丸見えになります。シークレットはサーバー側でしか保持できません。
もう一つは、そもそもブラウザのJSは生のSMTP(TCP)を喋れないこと。ブラウザから飛ばせるのはHTTPだけなので、「HTTPを受けてSMTPに変換する」中継役がどのみち要ります。
なので/api/contactの部分だけは実行時に動くサーバー関数として用意する必要があって、それ以外のページ(フォームのHTML自体を含む)は全部ふつうに静的なままでいい、というのが今回の構成です。サイトが完全に静的なだけなら、今回みたいな話はそもそも起きません。「一部だけサーバーサイドで処理したい」となった瞬間に、はじめてアダプターやデプロイ先の対応状況が問題になってきます。
まずnodejs_compatを疑った
Cloudflareのダッシュボードを開いたら「互換性フラグ、定義されていません」と出ていて、あーこれだこれだ、と早合点。wrangler.tomlにはちゃんとnodejs_compat書いてあるのに反映されてない、じゃあダッシュボード側で直接足せばいいじゃんと思って設定して再デプロイ。
直らない。
しかもリアルタイムログを開いて再現しようとしても「接続を待機しています」のまま何も流れてこない。これ、エラーが起きてるんじゃなくて、そもそもWorkerが呼ばれてすらいないパターンだ、と気づいた瞬間にちょっと血の気が引きました。
ビルドログをちゃんと読んだら答えが書いてあった
改めてビルドログを見返すと、毎回律儀にこう書いてあったんですよね。
A Wrangler configuration file was found but it does not appear to be valid… make sure the file is valid and contains the
pages_build_output_dirproperty. Skipping file and continuing.
今まで警告扱いで読み飛ばしてたんですけど、これ「無視してますよ」ってはっきり言われてる。wrangler.tomlも、ビルド後に自動生成されるwrangler.jsonも両方毎回スキップされていて、/api/contactを動かすためのWorkerスクリプトが一度もデプロイされていなかった。そりゃFunctionのログも無反応なわけです。
念のため補足すると、「サイト全体がSSRになった」わけではありません。フォームのページ自体は相変わらず静的なHTMLとして書き出されていて、動かす必要があるのは/api/contactという1本のエンドポイントだけです。ただ、Astroのビルドログにはmode: "server"と表示されるので、一見サイト全体が動的になったように見えて、最初はそこも誤解してました。
で、ここで初めて@astrojs/cloudflareの公式ドキュメントをちゃんと読みに行ったら、
The Astro Cloudflare adapter no longer supports deployment on Cloudflare Pages.
v13から普通にPagesサポートが削除されてました。ドキュメントに書いてあることを自分がちゃんと見てなかっただけ、という、わりとよくあるやつです。
じゃあWorkersに行けばいいじゃん、と思ったら
一瞬「Workersに移行すればいいだけじゃん」と思ったんですが、うちのカスタムドメインがクライアントによってはNSをCloudflareに向けたくなくて、サブドメイン運用(外部DNSでCNAME一本)で逃げていたんです。ただこれPages限定の仕組みで、Workersのカスタムドメインは普通にゾーンのNS移管が必須でした。なのでWorkersは要件的に使えない状況でした。
WorkersがPagesを飲み込みつつある、という流れ自体はうっすら知っていました。ただ「普通のサイトならPagesとWorkersの差がほぼない」と思っていて、実際これまでは、NSが既にCloudflareに向いている案件だけwrangler.jsoncとかの書き方の練習も兼ねてWorkersでデプロイして、それ以外はPagesのままという使い分けをしてました。今回それがついに立ち行かなくなったという話です。
というわけでWorkers移行は今回は選ばず、astroを5系、@astrojs/cloudflareをPages対応最終版の12.6.13まで下げて、とりあえず動く状態には戻しました。dist/_worker.jsと_routes.jsonが復活して、ビルドも型チェックも通ったので、目先の問題は解決です。
でもこれ、いつまでやるんだろうな、というのが正直なところ
ダウングレードして直った瞬間はほっとしたんですけど、冷静に考えると「Pagesが公式に見捨てられつつある製品を、バージョン固定してだましだまし延命させてる」だけなんですよね。次にまた何か機能を足したくなったときに、また同じ壁にぶつかる未来が見えてる。使い分けでごまかせる段階はもう終わっていて、Workersに統一しないといけないフェーズが来た、というのが今回の一番の実感です。
コード自体は別にCloudflareにベッタリ依存してるわけじゃなくて、むしろnodejs_compatまわりの特殊対応とかWorkersランタイムでのSSRの癖とか、素直なNode.jsサーバーに持っていったほうが苦労が少なそうな気配すらあります。なので「詰んだらよそに引っ越せばいい」という逃げ道はちゃんと用意できている状態ではあります。
とはいえCloudflareの料金の緩さは正直かなり魅力で、これを手放すのはもったいない。それに考えてみればCloudflareでDNSを管理すると伝播がほぼ一瞬なので、NSを持ってこない理由って結局「移行作業がちょっと面倒」くらいしか残ってないんですよね。それだけの理由で先延ばしにし続けるのも変な話だな、と思うと、腹をくくってNS移行をやってしまったほうが長い目で見ればプラスのほうが大きい気がしています。静的出力に振り切るとか別サーバーに逃がすとかも選択肢としては残しつつ、まあ次にPages周りで詰まったらNS移行本番かな、くらいの温度感で今は考えています。