cloudfare workers をもう少し理解する
#cloudflare
とりあえず今の理解は、V8ベースで動くエッジコンピュータ
一旦これだけ。
Input
hr.icon
https://zenn.dev/ak/articles/a2bd28a258b615
キーワード
CDN
エッジコンピューティング
JavaScript 実行環境
はい
このアメリカのサーバーのように、大元のデータを保存しているサーバーのことを「オリジンサーバー」と呼び、キャッシュしたコンテンツを配信しているサーバーを「エッジサーバー」もしくは「キャッシュサーバー」と呼びます。
あ、これをエッジサーバーっていうんですか
ちなみに、先ほど JavaScript 実行環境には「エンジン」があると説明しましたが、Cloudflare Workers では「V8」と呼ばれるエンジンが使われています。V8 は、ブラウザの Chrome や Node.js でも使われていて、高速で動作します。
へぇぇぇぇonigiri.w2.icon
https://zenn.dev/moutend/articles/97c98a277f4bae#cloudflare-workersを深く知る
このように、ユーザーに最も近い場所でサービスを提供する形態をエッジコンピューティングとよびます。
なるほど
従って、Cloudflare Workersはプロセス間の通信を行えません。また、異なるWorker同士で処理の結果を共有する場合はCloudflare KV、処理の結果を永続化する場合はCloudflare R2などの別サービスと連携する必要があります。
ほおonigiri.w2.icon
q.icon てか、KVってそういう用途なの?
紛らわしいのですが、サンドボックスで隔離されるのはWorker単位です。例えばhttps://aaa.example.workers.devとhttps://bbb.example.workers.devがあるとします。当然お互いのグローバル変数にはアクセスできません。
しかし、同じWorkerインスタンスであれば実行時の環境は引き継がれるためグローバル変数が参照できます。そのため、npx wrangler devを実行してローカルでWorkerを動作させる場合と、CloudflareのサーバーでWorkerを動作させる場合を比べると、挙動が異なるように見える場合があります。
これは覚えておかないといけない点だ。めちゃ重要
一見すると正しくインクリメントされていないように見えますが、それぞれのWorkerインスタンスでは正しくインクリメントされています。そのため、偶然に同じWorkerインスタンスが使い回されるとレスポンスとして2や3が返ってくる可能性はあります。
何にせよ、グローバル変数に依存した処理を実装するべきではありません。CloudflareのドキュメントにもWorkerインスタンスがどのタイミングで破棄されるのか言及がありません。基本的には、リクエストのたびに作成されて、処理の完了と同時に破棄されると考えて処理を実装するべきです。
まぁそうだな。
https://future-architect.github.io/articles/20230427a/