Edge Functions - Vercel についてざっくり理解
JJNext.js Conf 2021 で発表された Edge Functions on Vercel を理解する
JJまず大まかな理解としては JavaScript のコードを Edge で動かすことのできるものという理解
ここでいう Edge とは、 Vercel が世界中に持つ POP 上で動かすという意味として理解してる
docs にも以下のようにある
従来、コンテンツを配信する方法には、ユーザーの近くにあるCDN（Content Delivery Network）から静的に配信してレスポンスタイムを短縮する方法と、リクエストごとにサーバーレベルでパーソナライズを設定する動的な方法の2つがありました。
アプリケーションの訪問者にコンテンツを配信する方法を決定する際には、これらの2つのオプションが提供するトレードオフを考慮する必要があります。
静的なページは、世界中のどこにいても、すべての訪問者に同じコンテンツを配信することができ、CDNによってキャッシュされるため、高速に動作します。しかし、例えばユーザーが世界のどこにいるかに応じてパーソナライズされたコンテンツを配信したい場合、この方法は実行できないかもしれません。
ユーザーにパーソナライズされた体験を提供するには、サーバーサイドレンダリングを利用して、サイトページへの各リクエストに対して動的コンテンツを作成することができます。これにより、ユーザーの所在地に応じて異なるコンテンツを提供したり、ユーザーを認証したり、サイトの言語を設定したりすることが可能になります。
この方法の欠点は、処理速度が遅くなることです。リクエストを処理するサーバーが訪問者の発信元から離れている場合、リクエストが完了するまでに時間がかかり、純粋に静的なコンテンツを提供する場合のようなスピードでコンテンツをユーザーに提供できない可能性があります。
JJこれらの実装方法は Next.js 12 でもあった pages/_middleware.js の記述と同じように記述するだけっぽい
JJRuntime に関してはここに記述がある
Edge Functions が deploy されるとベースは V8 だけど限られた API が使えるようになったランタイムの中で実行される。また開発段階では本番ランタイムをエミュレートしたサンドボックス環境で実行される。
これらのことから以下のような制約がある。
- Node.js の Native API はサポートされない。例えば fs など。
- ES Modules を実装して Node.js の Native API を使ってない限りは npm modules を使うこともできる。
- ES Modules を使用してコードを再利用可能なファイルに分割し、アプリケーションのビルド時にまとめて使用することもできる
- require を使うことができない。import path が静的に解決できる場合は動く可能性があるが非推奨である。代わりに es modules を使うようにする
JJTechnical Details には Edge Functions の制約が書かれている。制約としてあるのは以下の2つである。
- Edge Functions の最大実行時間は 30s であるが、レスポンスを返すまでは 1.5s 以内にする 必要がある。レスポンスを返した後、バックグラウンドで非同期のワークロードを続行することは可能。
- Edge の関数の最大サイズはその関数にバンドルされている全てのコードを含めて 1MB にしなくてはならない。制限に達してしまった場合、関数に import されているコードが使用されているか、重すぎないかを確認する。 bundleのようなパッケージサイズチェックツールを使って代替品を探すなどする必要がある。