プラットフォーム向けワーカーの仕組み
プラットフォーム向けワーカーは、Cloudflare Workersの上に構築されています。プラットフォーム向けワーカーを使用するアプリケーションには、ワーカーで使用されるのと同じセキュリティとパフォーマンスモデルが適用されます。
ワーカーの構成APIは、各アカウントで比較的少数のワーカーを管理するために最初に構築されました。これにより、独自のユーザー向けのプラットフォームとしてワーカーを使用する際にいくつかの困難が生じます。具体的には：
- スクリプト制限を頻繁に増やす必要がある。
- 増え続けるルートを追加する。
- 自分のロジックが顧客のロジックの前に来るべき場合、中央でロジックを管理する。
プラットフォーム向けワーカーは、顧客のためにワーカーのスクリプトを展開したいSaaSビジネスのために、ワーカーの機能を拡張します。また、ユーザーが直接ワーカーのスクリプトを書くことを許可することもできます。
プラットフォーム向けワーカーは、このページに概説されている新しいアーキテクチャモデルを導入します。
ディスパッチネームスペースは、ユーザーのワーカーのコレクションで構成されています。ディスパッチネームスペースを使用すると、動的ディスパッチワーカーを使用して、ネームスペース内の任意のユーザーワーカーを呼び出すことができます。
動的ディスパッチワーカーは、Cloudflareのプラットフォーム顧客によって書かれ、リクエストをユーザーのワーカーにディスパッチ（ルーティング）する前に独自のロジックを実行します。ルーティングに加えて、認証を実行したり、ボイラープレート関数を作成したり、レスポンスをサニタイズするためにも使用できます。
動的ディスパッチワーカーは、ディスパッチネームスペースからユーザーのワーカーを呼び出し、それらを実行します。動的ディスパッチワーカーは、ディスパッチネームスペースバインディングで構成されます。このバインディングは、ユーザーのワーカーへのすべてのリクエストのエントリポイントです。
ユーザーワーカーは、エンドユーザー（エンド開発者）によって書かれます。エンド開発者は、ユーザーワーカーを展開して自動化されたアクションをスクリプト化したり、統合を作成したり、レスポンスペイロードを変更してカスタムコンテンツを返したりします。
以下に、プラットフォーム向けワーカーアーキテクチャにおけるリクエストライフサイクルの例を示します。
上記の図では：
customer-a.example.com/apiへのリクエストは、最初に動的ディスパッチワーカー（api-prod）に到達します。- 動的ディスパッチワーカーコードに設定されたディスパッチャー（
env.dispatcher.get(customer-a)）がユーザーのワーカーへのルーティングロジックを処理します。 - 受信リクエストのサブドメイン（
customer-a.example.com）が、同じ名前のユーザーワーカー（customer-a）へのルーティングに使用されます。
プラットフォーム向けワーカーとサービスバインディングの両方が、ワーカー間の通信を可能にします。
サービスバインディングは、2つのワーカーを明示的にリンクします。これは、どのワーカーが互いに通信する必要があるかを正確に知っているユースケース向けに設計されています。サービスバインディングは、ユーザーのワーカーが必要に応じてアップロードされるため、プラットフォーム向けワーカーのモデルでは機能しません。
プラットフォーム向けワーカーのモデルでは、動的ディスパッチワーカーを使用して、ディスパッチネームスペース内の任意のユーザーワーカーを呼び出すことができます（サービスバインディングの動作に似ています）が、関係を明示的に事前定義する必要はありません。
サービスバインディングとプラットフォーム向けワーカーは、アプリケーションを構築する際に同時に使用できます。
プラットフォーム向けワーカーのユーザーワーカーは、キャッシュAPIを通じて名前空間付きキャッシュにアクセスできます。名前空間付きキャッシュは、ユーザーのワーカー間で隔離されています。隔離のために、caches.default()は名前空間付きスクリプトでは無効になっています。
キャッシュについて詳しく知りたい場合は、キャッシュの仕組みを参照してください。