Cloudflare Workers RPC を知ってほしい
-- Views
September 18, 25
スライド概要
プログラマー👨💻
関連スライド
Meta XR SDK(V66-74)でQuestアプリを開発
あうぜん
1.1M
各ページのテキスト
Cloudflare Workers RPC を知って ほしい 2025/09/18 TECH PLAY主催LT大会 #1
自己紹介 shinshin ● 株式会社フクロウラボのバックエンドエンジニア ● 地方在住エンジニア ● o11y と関数型プログラミングが気になっている
Cloudflare Workers とは ● サーバーレスのアプリケーションプラットフォーム ● エッジロケーションで JavaScript が動く ○ ● Google が開発した実行エンジン V8 同じくエッジロケーションで動くAWS サービスとして Lambda@Edge
Cloudflare Workers の RPC とは ● Cloudflare Workers 間の通信に RPC 接続を使える機能 ● 同一 Worker の関数を呼び出すかのように、異なる Worker を呼び出すことができ る ● 通信する Worker を設定ファイルに宣言するだけで OK ● 呼び出しは同一スレッド内で処理される
呼び出し先 Worker
呼び出し元 Worker
Cloudflare Workers RPC の嬉しさ
スキーマレスでも安全な開発 ● 経験上、API 開発はスキーマ駆動で進めて、スキーマからコード生成する開発スタ イルが多い ○ 短期的な開発速度が必要な開発や、開発が活発な PJ初期はスキーマ変更やコード生成がちょっと 辛い ● RPC を TypeScript で実装すれば、型の共有により安全な開発ができる ○ ● エントリポイントを import する CI での型チェックで変更の追従漏れにも気がつける
認可不要の通信 ● ここでいう認可不要というのは、一般的な API 通信などにあるトークンや API キー を使った認可が不要であることを指します ● 通信はデプロイ時に明示的に設定した Workers 間でのみ可能 ○ ● 同一アカウントの Worker 間のみ 外部からの通信は遮り、内部での通信は簡単な設定で実現
Cloudflare Workers RPC の苦しさ
デバッグが困難 ● HTTP で喋る API のようにエンドポイントを叩いて挙動確認、といったことが難しい ● 呼び出し口は JavaScript の class なのでコードから呼び出す必要あり ○ 開発時のみのデバッグ用に HTTP のエンドポイントを空けて任意のエントリポイントに流せるように する、といった力技もあるが ...
チーム内での API 設計方針のブレ ● REST や GraphQL とは異なった形式でのエントリポイント定義になるので、チーム 内でのブレは生まれやすい ● 開発者によって手続きベースでのエントリポイント定義をしたり、REST のようなリ ソースへの操作ベースの定義をしたり... ● 実践例やベストプラクティス的なものも世に出ていない ● (当然のことだが)チーム全体で方針を擦り合わせないと一貫性のない設計になり やすい
まとめ ● Cloudflare Workers RPC によって、複数の Worker 間通信がより簡単にできる ● 性能やセキュリティの観点でもメリットがある ● 新しめの機能なので情報が少ないこともあり、挙動の把握に苦しんだりチームでの 設計方針に手こずることもある ○ その点を理解した上で採用するべき