- 実際のCloudFlare Workersで使われているJavaScript/WASMランタイムコード
- 他の環境に移植できるように一部のみ変更
- 名前はUnixサーバーの -d "daemon" に由来し、「worker dee」と読む
用途
- Workersをセルフホスト可能。単純にAPIとして利用できるWebサーバーでもあり、どのような環境にも簡単に適用可能
- ローカル開発およびテスト用に使用
- プログラム可能なプロキシ(フォワード&リバース)。JavaScriptでリクエスト/レスポンスを横取りして処理可能
What it is
- Server-first : 多くのJS/WASMランタイムは多目的に使えるが、workerdはサーバーのみに集中。中でもHTTPサーバー向け
- Web standard APIs : Webブラウザーで使われているのと同じ標準APIを提供(Fetch, URL, WebCryptoなど)。つまりここで開発したコードはブラウザーへ移植することも可能
- Nanoservices : いまやマイクロサービスを超えてナノサービス!
- ナノサービスは、独立したデプロイの利点と、ライブラリ関数呼び出し程度のオーバーヘッドだけを持つ新しいモデル
- workerdを使えば、多数のWorkerを同じプロセス内で構成でき、各Workerは独立して実行されながら相互通信も可能
- Homogeneous deployment : 以前は特定のコンテナで特定のサービスを実行する必要があったが、workerdではすべてのマシンがすべてのサービスを動かせる
- Capability bindings: すっきりした設定とSSRF安全性を保証
- Always backwards compatible : 常に下位互換性を保証
What it's not
- workerd is not a Secure Sandbox : 悪意あるコードが実行される可能性がある。これを防ぐには別途サンドボックス層が必要
- workerd is not an independent project : Cloudflare Workersの中核であり、その一部。外部からのコミットは受け付けるが、保証は難しい。
- workerd is not an off-the-shelf edge compute platform : Workersサービス全体ではない
2件のコメント
公開されたら作ってみたかったものだけど、おお。
これがどういう意味なのかと思いましたが、すぐ前で説明されているナノサービス(functions)方式で開発するようになると、すべてのナノサービスを1台のマシンにそのままデプロイできて(オーバーヘッドが小さいので可能とのこと)、必要なら同じマシンをそのまま増やせばよいので、複雑なデプロイ構成が不要になる、という意味だったんですね。