サーバーレスサーバーと新しい React アーキテクチャの課題

最近のヴェルセル お知らせをツイートしました 新しい Vercel Functions 機能の場合:

サーバーレスサーバー: 機能内同時実行機能を備えた Node.js

• Vercel Functions 用に最適化された Node.js 同時実行モデル
• プライベート ベータ版の顧客 @madeonverse はコンピューティング コストを 50% 削減しました
• オプトインパブリックベータ版として本日より利用可能

意図的かどうかに関係なく、このツイートは多くの注目を集め、「サーバーレスサーバー」という一見ナンセンスなフレーズのおかげで無数のミームの反応を引き起こしました。一方で、それはまさにソーシャル メディアの仕組みであり、人々は楽しみながら農作業に参加することを好みます。一方で、多くの人が Vercel とその製品に対して強い意見を持っているため、Vercel のニュースには必ず何らかの話題が生まれます。いずれにせよ、多くの人がこのフレーズをからかうことをやめて読み飛ばしているようであるのは少し残念です 新機能を説明するリンクされたブログ投稿。

関数内同時実行によって解決される内容の概要は次のとおりです。 Vercel Function の呼び出しごとに、Node.js プロセスである新しい関数インスタンスが起動されます。元のセットアップでは、各インスタンスが分離されているため、Node.js の同時実行性を最大限に活用できませんでした。これにより、ジョブに非同期呼び出しが含まれる場合、Promise が解決するのを待っている間、各関数インスタンスが単にアイドル状態になるため、非効率性が生じていました。新しい関数内同時実行性は、各インスタンスが複数のリクエストを同時に処理できるように、受信した関数呼び出しリクエストを既存のインスタンスに転送することでこの問題を解決します。

これは明らかに大幅な効率の向上であり、多くの Vercel Function ユーザーはすでにコンピューティング コストの大幅な削減を実感しています。しかし私にとって、この新機能はまた、 React の新しいフルスタック アーキテクチャ ビジョン フレームワーク以上のものが必要であり、Vercel のような製品はほぼ必然です。

新しい React アーキテクチャの基礎は、React アプリがサーバー部分とクライアント部分の両方で構成されることです。 React アプリ開発者は、データ管理をサーバー部分に限定し、クライアント部分を無駄のない状態に保つことが推奨されます。この変更には、少なくとも 2 つの影響があります。1 つはサーバーへのトラフィックの増加 (サーバー上のコンポーネントをレンダリングするため)、もう 1 つはサーバー上の非同期呼び出し (サーバー上のコンポーネントからの) の増加です。アプリが一部のサーバー データを変更し、最新のデータに基づいてビューを更新するシナリオを考えてみましょう。以前は、これは主に、外部 API エンドポイントを直接呼び出してビューの更新を処理することで、クライアント側で処理できました。新しい React アーキテクチャでは、これは通常、データのフェッチとそのデータを使用したコンポーネントのレンダリングの両方を行う React のサーバー部分を経由します。

Next.js の場合、そのコントラストはより顕著です。フルスタック React アーキテクチャの事実上の標準実装である App Router は、サーバー側 React だけでなく、ネストされたルートのサポートを追加しました。これにより、開発者は、データ要件をミラーリングするために、より詳細なルートを備えたアプリを構築することが奨励されます。 App Router のサーバーからすべてのルートを開始するアプローチと組み合わせると、サーバー ツリー全体を再構築するためにサーバー上のすべてのコンポーネント内で取得されたすべての関連データを解決する必要がある場合、より多くのサーバー トラフィックが発生する可能性があります。サーバーへのトラフィック (サーバー上のコンポーネントをレンダリングするため) とサーバー上の非同期呼び出し (サーバー上のコンポーネントからの) が増加します。

Next.js は、その影響を軽減します。 洗練されたキャッシュメカニズム データのフェッチとコンポーネントのレンダリングに使用されます。ただし、これはデータとビューを頻繁に更新する動的アプリの場合に限られます。真にスケーラブルにするためには、分散展開のためのインフラストラクチャによるサポートが必要です。 そこにヴェルセルが登場する。

では、この話はサーバーレスサーバーと機能内同時実行にどのように関係するのでしょうか? Next.js を Vercel にデプロイするということは、 Vercel Function を使用してトラフィックを処理する:

Vercel では、Node.js ランタイム (デフォルト) のいずれかで Next.js アプリケーションをサーバー レンダリングできます。 サーバーレス機能 または Edge ランタイム エッジ機能。

App Router が登場する前は、呼び出しごとに 1 つのインスタンスを設定するコストはそれほど目立っていなかったように思いますが、App Router のサーバー ニーズの増加により、この制限が注目されるようになりました。 Vercel にデプロイされている非常に多くのアプリが Next.js アプリであることと、App Router の人気が高まっていることを考えると、関数内同時実行によるコストの劇的な削減は、App Router で大規模な Next.js アプリを提供することによるものではないかと思います。

もちろん、より大きな話は、React、Next.js、Vercel 間の垂直方向の連携がますます強くなったことです。この調整に邪悪な陰謀は必要ありません。むしろ、これは、サーバー クライアント モデルを特定の方法で採用しようとする React の新しいアーキテクチャの課題を示しています。 React アプリがクライアント側のみだったとき、そのコンポーネント指向のコストはほとんど隠れていました。確かなパフォーマンスですが、UX のコストの矢面に立つのはユーザーであり、開発者への影響は多くの場合せいぜい間接的なものでした。 React がサーバー側に移行すると、このコストが請求書に反映され始めます。クライアント側とサーバー側の両方をカバーするのはフレームワークの仕事ですが、それを効率的にするにはインフラストラクチャからのサポートが必要なようです。おそらくフルスタック React への新しいアプローチによって、これを変えることはできるでしょうか?

更新 (2024-10-08): Theo のフィードバックに関するメモ

最新のライブストリームでのサーバーレス サーバーのニュースの取材中に、Theo (@t3dotgg) がこの投稿を紹介し、フィードバックを提供してくれました。 (ありがとう!) Theo 氏は、関数内同時実行による本当の利点は、複数の遅い非同期リクエストを同時に処理できることにあり、本質的に同期しているサーバー上でコンポーネントをレンダリングすることとはほとんど関係がないことを指摘しました。 これは完全に正しいです！ 関数内同時実行は、純粋なレンダリングなどの Vercel Function インスタンスで実行される同期タスクの最適化には関係ありません。

それを念頭に置くと、この話にはまだ続きがあると思います。フルスタック React は、データのフェッチをクライアント側の React からサーバー側の React に移動することを推奨しています。 await サーバー上で非同期コンポーネントをレンダリングする際のデータ取得リクエスト。最初のコード例は次のとおりです データ取得に関する Next.js ドキュメント ページ 逐語的に:

async function getData() {
  const res = await fetch("https://api.example.com/...");
  // The return value is *not* serialized
  // You can return Date, Map, Set, etc.

  if (!res.ok) {
    // This will activate the closest `error.js` Error Boundary
    throw new Error("Failed to fetch data");
  }

  return res.json();
}

export default async function Page() {
  const data = await getData();

  return main>main>;
}

このようなコンポーネントのレンダリングは、もはや純粋な計算ではありません。 関数内の同時実行性により、それぞれ await コンポーネント本体内では、Vercel が同じ関数インスタンスを使用してより多くのリクエストを処理する機会が得られます。各データ取得呼び出しにかかる時間が長ければ長いほど、節約効果は大きくなります。

とはいえ、Next.js が API ルート経由でサーバー上でユーザー コードを実行できることを認識していませんでした。 getServerSidePropsなど、何年にもわたって！したがって、Vercel にデプロイされた Next.js アプリを、API ルートなどを介してデータを取得する Page Router から、サーバー上のコンポーネントからデータを取得する App Router に移行する場合、どの環境にあるかに関係なく、全体のコンピューティング コストに大きな違いはありません。 -関数の同時実行性。これはおそらく、私が行った次の声明を無効にする可能性があります。「関数内同時実行によるコストの劇的な削減は、App Router で大規模な Next.js アプリを提供することによるものではないかと思います。」

しかし全体的に見て、この記事の基本的なポイントは依然として有効であると私は信じています。つまり、フルスタック React アーキテクチャとそのデータ取得パターンは大規模なサーバー コストに重要な影響を及ぼし、それらに効果的に対処するにはフレームワーク以上のものが必要であるということです。 Vercel のような専用の導入インフラストラクチャが必要です。