Cloudflareは、Next.jsアプリをVite上で実行し、Cloudflare Workers、Netlify、AWS Lambdaなどのプラットフォームにデプロイできるオープンソースフレームワーク、Vinextの1.0をリリースした。このプロジェクトは、Pages RouterまたはApp Routerを使用するアプリを含む、新規アプリと既存プロジェクトを対象としており、Next.jsの新しい構成だけにサポートを限定していない。
Next.jsアプリとのより広範な互換性
Vinextは、2月のローンチ時に1週間続いたAI主導の実験から、トラフィックが多く動的なアプリで本番利用されているとCloudflareが述べるフレームワークへと移行した。同社によると、顧客が求めた機能の大半との互換性は99%を超えており、同じ名前のAPIを単に模倣するのではなく、アプリの実際の挙動を引き続きテストしている。
このリリースは、App RouterとPages Routerの両方に加え、ハイブリッドアプリ、Reactサーバーコンポーネント、サーバーアクション、APIルート、ルートハンドラー、ミドルウェア、クライアントサイドナビゲーションをサポートする。また、サーバーサイドでのページのレンダリング、増分静的再生成（ISR）、静的アセットへのエクスポート、バックグラウンドまたはオンデマンドでの再検証にも対応する。
実際には何が変わるのか？
Vinextは、両方のルーターとサポート対象の実行環境にまたがるキャッシュ機能を統一し、Workers Cacheにも対応する。また、Next.js互換のトレース機能を提供するため、既存のOpenTelemetryとSentryの設定を継続して利用でき、Cloudflare Workers上ではWorkersネイティブの監視ツールと統合される。
このリリースでは、開発時と本番時のworkerd環境を直接サポートし、画像最適化やHyperdriveなどのCloudflareリンク機能にアクセスできる。一方、Cache Componentsに関連するuse cacheディレクティブのサポートは限定的なままである。Cloudflareは、現在の優先事項は本番アプリが依存するフレームワークの中核機能だと説明している。
リリース前のキャッシュウォームアップ
Vinext 1.0は、ビルド中にApp RouterとPages Routerのページを事前レンダリングし、その後ISRを通じて提供し、ルートまたはタグに基づいて無効化する仕組みを提供する。ただし、数万または数十万のURLを含むアプリ向けに、事前レンダリングの一部をビルドマシンからCloudflareのネットワークへ移す別のオプションも追加している。
cache warming機能は、Next.jsで通常使われる指標を利用して準備すべきページを特定し、トラフィックの多いページを特定することもできる。新バージョンを本番トラフィックに移行する前に、Cloudflareはトラフィック比率0%でWorkerのバージョンをデプロイし、そのバージョンからページをリクエストしてキャッシュを埋める。処理が完了した後、デプロイを昇格させることができる。これにより、アクセスの少ないページを順番にビルドする際の待ち時間を短縮できるが、この機能を使用する場合は、実質的にCloudflareへのデプロイと結び付いている。
テストと移行の手順
Cloudflareによると、このプロジェクトでは、フレームワークの挙動、開発および本番モードのサーバー、Node.jsとCloudflare Workersへのデプロイ先を対象とする数千件のテストを実施している。また、上流の変更によるリグレッションを検出するため、包括的なNext.jsテストスイートを毎晩Vinext上で実行している。移行プロセスには、プロジェクトの互換性、Viteの設定、デプロイ設定を確認する2つのコマンドが含まれており、従来のNext.jsプロジェクト構造を維持できる。コマンドはnpx vinext check、続いてnpx vinext initである。
Vinextは新規プロジェクトと既存プロジェクトで利用でき、npx @vinext/cloudflare deploy --warm-cacheコマンドを使えば、キャッシュウォームアップを有効にしてCloudflare Workersへデプロイできる。互換性マトリクスと、Cache Componentsなどの未完成の機能サポートは、複雑なアプリで移行を採用する前にチームが確認すべき点として残っている。