リモートバインディングは、ローカルでシミュレートされたリソースではなく、Cloudflareアカウント上にデプロイされたリソースに接続するバインディングです。当社は最近、リモートバインディングが一般に利用可能になったことを発表しました。
このリリースにより、ローカルマシンでWorkerコードを実行しながら、R2バケットやD1データベースなどのデプロイされたリソースに接続できるようになりました。つまり、反復ごとにデプロイするオーバーヘッドをかけずに、実際のデータやサービスに対してローカルコードの変更をテストできるのです。
このブログ記事では、当社がどのようにしてシームレスなローカル開発体験を実現したかについて、技術的な詳細を掘り下げます。
Cloudflare Workersプラットフォームの重要な部分は、何かをテストしたいたびにコードをデプロイすることなく、ローカルにコードを開発できる能力です。しかし、これをサポートする方法は、数年にわたって大きく変化しました。
リモートモードでwrangler開発を始めることから始めました。これは、コードに変更を加えるたびにCloudflareのネットワーク上で実行されるWorkerのプレビューバージョンをデプロイして接続することで機能し、開発時にテストすることができます。ただし、リモートモードは完璧ではありません。複雑で保守が難しいのです。イテレーション速度が遅い、デバッグ接続が不安定、マルチWorkerシナリオのサポートがないなど、開発者体験には多くのものが含まれています。
これらの問題などをきっかけに、Workersの完全ローカル開発環境への多額の投資が動機となりました。2023年半ばにリリースされたこの開発環境は、wrangler開発のデフォルト体験になりました。それ以来、当社はCloudflare Viteプラグイン、Wrangler、Cloudflare Viteプラグイン（@cloudflare/vitest-pool-workersとともに）とMiniflareを使って、ローカル開発エクスペリエンスに膨大な努力を費やしてきました。
それでも、元のリモートモードは、フラグ wrangler dev --remote を介してアクセス可能なままでした。リモートモードを使用すると、完全にローカルな体験とここ数年にわたって行ってきた改善がバイパスされてしまいます。では、なぜいまだに使われているのでしょうか？Cloudflareのユニークな特徴は、ローカルで開発しながら、リモートリソースへのバインディングです。ローカルモードを使用してWorkerをローカルに開発する場合、すべてのバインディングがローカルの（最初は空の）データを使用してローカルでシミュレートされます。これは、テストデータを使用してアプリのロジックを反復処理するのに最適ですが、チーム全体でリソースを共有したい、実際のデータに関連したバグを再現したい、または実際のリソースを使用して本番環境でアプリが動作することを確認したい場合など、不十分です。 .
そこで、当社は好機だと考えました。リモートモードの優れた部分（つまり、リモートリソースへのアクセスなど）をwrangler devに知らせるための単一のフローがあり、ローカル開発の進歩をユーザーにロックアウトすることなく、多くのユースケースを可能にします。そして、それが私たちの取り組みです。
Wrangler v4.37.0現在、バインディングがリモートリソースを使用するか、ローカルリソースを使用するか、バインディングごとに選択できるようになりました。リモートオプションを指定するだけです。これを再度強調することが重要です。remote: true! を追加するだけで済みます。API キーや認証情報の複雑な管理は必要ありません。すべては、Wrangler の既存の Oauth 接続を使用して Cloudflare API に機能します。
{
"name": "my-worker",
"compatibility_date": "2025-01-01",
"kv_namespaces": [{
"binding": "KV",
"id": "my-kv-id",
},{
"binding": "KV_2",
"id": "other-kv-id",
"remote": true
}],
"r2_buckets": [{
"bucket_name": "my-r2-name",
"binding": "R2"
}]
}
鋭い方は、ローカル開発者からリモートリソースにアクセスして、すでにいくつかのバインディングが機能していることに気づいているかもしれません。最も顕著なのは、AIバインディングが、一般的なリモートバインディングソリューションがどのようなものかを示す先駆者でした。Workers AIで使用できるすべての異なるモデルをサポートする真のローカル体験は現実的ではなく、AIモデルの膨大な事前ダウンロードが必要だからです。
Workers内のさまざまな製品がリモートバインディングに似たものを必要としていることに気づくと（たとえば、ImagesとHyperdriveなど）、異なるソリューションの寄せ集めのようなものになりました。現在、すべてのバインディングタイプに対して機能する、単一のリモートバインディングソリューションに統合されています。
私たちは、本番用のWorkersコードを変更することなく、開発者が本当に簡単にリモートリソースにアクセスできるようにしたかったのです。そこで、Workerで使用する時点でリモートリソースからデータを取得するというソリューションを使いました。
const value = await env.KV.get("some-key")
上記のコードスニペットは、env.KV KVネームスペースの「some-key」値にアクセスすることを示しています。これは、ローカルでは利用できず、ネットワーク経由で取得する必要があります。
では、それが私たちの望む要件だとしたら、どのようにして関係を構築するのでしょうか？例えば、Workerでenv.KV.put(「key」、「value」）を呼び出すユーザーから、実際にリモートKVストアに保存するにはどうすればいいでしょうか。明らかな解決策は、Cloudflare APIを使うことかもしれませんでした。ローカルにEnv全体をAPI呼び出しを行うスタブオブジェクトで置き換え、env.KV.put()をPUT http:///accounts/{account_id}/storage/kv/namespaces/{namespace_id}/values/{key_name}に変換することもできました。
これは、KV、R2、D1など、成熟したHTTP APIを持つバインディングではうまく機能したでしょうが、実装と保守がかなり複雑なソリューションになったでしょう。バインディングAPIサーフェス全体を複製し、バインディング上で可能なすべての操作を同等のAPI呼び出しに変換しなければならなかったでしょう。さらに、バインディング操作の中には同等のAPI呼び出しがないため、この戦略ではサポートできません。
むしろ、すぐに使えるAPIがあったことに気づきました。私たちがプロダクションで使っているのです。
Workersプラットフォームのほとんどのバインディングは、本質的にサービスバインディングに集約されます。サービスバインディングは、2つのWorkers間のリンクであり、HTTPまたはJSRPC（JSRPCについては後ほど説明します）経由で通信できます。
例えば、KVバインディングは、認可されたWorkerとプラットフォームWorkerの間のサービスバインディングとして実装され、HTTPの話となります。KVバインディング用のJS APIはWorkersランタイムに実装されており、env.KV.get()のようなコールをKVサービスを実装するWorkerへのHTTPコールに変換します。
本番環境におけるKVバインディングの仕組みを示す簡略モデルを示す図
env.KV.get()呼び出しを翻訳するランタイムと、KVサービスを実装するWorkerの間に、自然な非同期ネットワーク境界があることに気づくかもしれません。そして、その自然なネットワーク境界を利用して、リモートバインディングを実装できることに気づきました。本番環境 ランタイムが env.KV.get() を HTTP 呼び出しに変換する代わりに、ローカル ランタイム (workerd) が env.KV.get() を HTTP 呼び出しに変換し、本番環境ランタイムをバイパスして KV サービスに直接送信することができます。Cloudflareはこれを実現したのです！
単一のKVバインディングでローカルで実行されるworkerを示す図。リモートプロキシサーバーに通信する1つのリモートプロキシクライアントがあり、そのクライアントがリモートKVと通信する
上の図は、リモートKVバインディングで実行されているローカルWorkerを示しています。ローカルKVシミュレーションではなく、リモートプロキシクライアントによって処理されるようになりました。次に、このWorkerは、実際のリモートKVリソースに接続されたリモートプロキシサーバーと通信し、最終的にローカルWorkerはリモートKVデータとシームレスに通信できます。
各バインディングは、リモートプロキシクライアント（すべて同じリモートプロキシサーバーに接続されている）またはローカルシミュレーションによって独立して処理でき、図のように、一部のバインディングはローカルでシミュレートされ、他のバインディングは実際のリモートリソースに接続する、非常に動的なワークフローが可能になります。下の例にあるものです：
上の図と設定は、2つのローカル（KVとR2）、1つのリモート（KV_2）という3つの異なるリソースにバインドされたWorker（お客様のコンピューター上で実行）を示しています。
上記のセクションでは、HTTP接続（KVやR2など）に支えられたバインディングについて説明していますが、最新のバインディングはJSRPCを使用しています。つまり、ローカルで実行しているworkerdが本番ランタイムインスタンスにJSRPCを通信するための方法が必要だったのです。
その時、幸運なことに、Cap'n Webのブログで詳述するように、これを可能にするための並行プロジェクトが進行していました。ローカルworkerdインスタンスとリモートランタイムインスタンス間の接続をCap'n Webを使ってwebsocketで通信することで、これを統合し、JSRPCに支えられたバインディングが機能するようにしました。これには、画像のような新しいバインディングや、独自のWorkersへのJSRPCサービスバインディングが含まれます。
Vite、Vite、JavaScriptエコシステムとのリモートバインディング
このエキサイティングな新機能をWrangler開発だけに限定したくありませんでした。Cloudflare Viteプラグインとvitest-pool-workersパッケージでサポートし、JavaScriptエコシステムの他の潜在的なツールやユースケースにも恩恵を受けられるようにしたいと考えました。
これを実現するために、wranglerパッケージはstartRemoteProxySessionなどのユーティリティをエクスポートし、wrangler開発を活用しないツールもリモートバインディングをサポートできるようになりました。公式のリモートバインディングドキュメントに詳細を記載しています。
Wrangler開発を使うだけ！Wrangler v4.37.0（@cloudflare/vite-plugin v1.13.0、@cloudflare/vitest-pool-workers v0.9.0）より、リモートバインディングはすべてのプロジェクトで利用可能で、バインディングごとに追加することで有効にすることができます。remote: trueは、Wrangler設定ファイルのバインディング定義に当てはまります。