00:07
はい、7月27日、時刻は朝9時を回りました。
本日の東京はすごく良い天気らしいですけど、 途中ライブになるらしいですね。
はい、おはようございます。ひめみのきーすことくわはなです。
では本日も朝活を始めていきたいと思います。
昨日ですね、みずちさんのEdge Side Front Endという 新領域というタイトルのスライドを読んでまいりましたので、
そこでがっつりと僕もクラウドフレアワーカーズという 唯一のツールにどっぷりと魅了されてしまいましてですね、
今日はその辺を追っていきたいというところで、
そもそもスライドに出てきた WinterCGというグループがあって、
そこのサイトがあるんですけど WinterCG.orgというサイトがあって、
そこのサイトを、まずワークスとかFAQというのがあるので、
その辺がどんな感じなのかという概要だけ つかんでいきたいなと思いました。
続いてもう一個ですね、How Workers Worksという記事があります。
これはクラウドフレアドックスという、 クラウドフレアさんが出しているブログですけど、
そこの記事のLearningというカテゴリーの中にあります。
How Workers Worksというのがあるので、 その辺をちょっと見ていこうかなと思います。
あと時間があれば他何か読みたいんですけど、
How the Cash Worksをついでに読もうかなと思ってます。
そんな感じで今日も伸びていきたいと思います。
ではまず、WinterCGですね。
WinterCGってところですね。
いつも通り翻訳をしていくので少々お待ちください。
はい、聞きましょう。
えっと、あ、そうか、すみません。
えっとですね、ピンマイクをつけ忘れたんですが、
ちょっと今一瞬かさっと音するかもしれないです。
OK、じゃあピンマイクつけたんで。
えっと、音声変わったのかどうかちょっと比較しないですけど、
これで多分音声も改善したと勝手に思ってます。
はい、じゃあ行きましょう。
WinterCGっていうグループですね。
Web Interoperable Runtimes Community Groupというふうに言ってますね。
はい、このコミュニティっていうのは、
JavaScript RuntimeのためにAPIの相互運用性について
協力し合う場を提供することを目的としています。
私たちはランタイム、特にフィーブラウザ間の
WebプラットフォームAPIの相互運用性を文書化し、
改善することに重点を置いています。
これはランタイム間の議論、また新しいWebAPIや
現在のWebAPIの変更に関する使用の場、
WATはWAGとW3Cでの提案とか、
既存のランタイムの動作の文書化などを通じて行われます
というふうに言ってます。
はい、一応そうですね。
昨日も読んでいた水井さんの記事内にも書かれてますけども、
03:01
ブラウザ外のJavaScriptの相互運用性について
非常に策定しているようなものというところで、
今回ここに関わっている団体は結構すごくてですね、
そうですね、クラウドフレアはもうそうですし、
Dのですね、あとバーセルも関わってますし、
ショピファイも関わってますし、
エガリアというところも関わってますし、
あとバイトダンスですねというところで、
いろんないろんなたる企業さんが関わっている
WinterCGというグループですね。
ここをちょっとどんな感じなのかというのを
見ていきたいなと思っていました。
はい、かいさんですね。
おはようございます。
タイトルのある記事をダラダラと読んでいる感じです。
まず最初WinterCGのワークというところですね。
ワークのところはでもページ開きたんですけど、
だいたいリポジトリへのリンクぐらいですかね。
Common Minimum APIとWeb Crypto Streamsと
あとPerformancesの3つについて
それぞれのリポジトリのリンクが張られているぐらいなので、
このページはそんなに読まなくて、
読むところがほぼないって感じですかね。
一応なんかスペシフィケーションで、
それぞれ記事もなくはないですけど、
これもちょっと棒体なのと、
あまり読ませる系の記事ではなくて、
あくまで使用策定したとき決め事の
羅列だったりするので、
これはちょっと今回読む対象に
じゃないほうがいいなと思いました。
続いてFAQですね。
WinterCGに対するFAQというところを
読んでいこうかなと思います。
まず最初What is the WinterCG?
というところですね。
Web Interoperable Runtime Community Group
WinterCGですね、略して。
というのはWeb Platform APIを
ブラウザー以外で使用すること。
すなわちサーバー上、
エッジランタイムですね。
クラウドフレアワーカーやリーダーに
興味を持つ人たちのコミュニティですと。
WinterCGはW3Cコミュニティグループとして
組織されています。
これにより同グループはW3Cの
棒体なインフラとIPRポリシーの
作業にアクセスすることができます。
これはWICCが組織されているコミュニティと
同じタイプですよと言ってます。
まずはざっくりと概要のところでしたね。
いろんな団体を集めてサーバー上で動く
エッジランタイムに興味を持つ人たちの
コミュニティですね。
Webを離れてJavaScriptをどうやって
動かすかというところの議論は
もうちょっと注目がありましたよと。
私も一応ノードJSで一応お仕事をしてたことは
過去にありますので、その辺に関わった身としては
興味が出てきましたね。
続いて、あとはWeTryingToDoですね。
我々は何をしようとしているのかというところです。
このグループの最終的な目標というのは
ブラウザー、サーバー、組み込みアプリケーション、
エッジランタイムなど使用しているランタイムに
関係なくJavaScript開発者が信頼できる
包括的な統一APIサーフェイスというのを
サポートするランタイムを推進することですと。
06:02
期待してます。
めちゃめちゃ魅力的なワードなので。
JavaScriptの世界に新たな変革が起きるというのを
期待してます。
続いてHowDoWeWantToAchieveOurGoalsですね。
続いて我々はどのように目標を達成したいんでしょうか
というところですけど。
サーバーサイドのランタイムが
WebプラットフォームAPIをどのように実装するのが
ベストなのか、またどの程度までブラウザーから
一達できるのかについてガイダンスドキュメントを
提供したいと考えています。
ブラウザー以外のランタイム視点から
WebプラットフォームAPIの使用作成者に
フィードバックを提供し将来の使用変更について
充分な情報を得た上での意思決定を支援したいと
言っています。
すべてのJS開発者のための包括的な統一APIサーフェース
という目標に役立つと思われる既存の
WebプラットフォームAPIの更新を既存の場で調整し
提案をしたいと。
ということは各企業にもやり取りするとか
アクセスをするという感じですかね。
ブラウザーを提供しているGoogleとか
AppleとかあとはModularとかともちゃんと連携を取って
進めていく感じなんですかね。
だとしたらかなり期待ができるのかなと思ったり
しました。
もちろん議論する側でどこまで連携し合えるとか
協力し合えるのかちょっと難しい話では
いいんですけど。
でもJSの使う我々開発者コミュニティの未来のことを
考えていろいろやってくださっているのはすごく
嬉しかったです。
続いてWhat are we doing this?
What?
Why?
Why are we doing this?
なぜこのようなことをするんでしょうかと。
このクループのメンバーはJSランタイムのための
フォーカス的な統一APIサービスというのがJSコミュニティ
全体に利益をもたらすものであるという信念を
まず共有しています。
過去にはメンバーは個々にこれを実現するために
活動していたというところもあります。
上背景になります。
このバラバラなアプローチとほとんど連携がないため
あまり歴史的にブラウザーベンダーや
仕様作成者だったりとかその他の実装者だけでなく
ブラウザー以外の実装者同士でも統一APIの話題でも
多くの混乱は出てきました。
これは議論がさまざまなバラバラなイシューとか
プロジェクトコメントで分散していて
それらの間にほとんど脈絡やまとまりがないことが
多かったのが原因じゃないかというところですね。
我々はより緊密に協力することでブラウザーベンダーや
仕様編集者にブラウザー以外のJSランタイムの
ユーザーからのより有意義なフィードバックを
提供できると考えています。
これはJSランタイムの包括的な統一APIサーフェス
という目標に関連する将来の仕様変更について
情報に基づいた決定を下すに役立つでしょうと。
逆に言うとブラウザーベンダーとかW3Cとか
仕様作成者との連携もそうですけど
僕ら実際JSを使った開発者たちと
09:00
ウィンターCGというところの連携の仕方とか
そこの中の人たちとの関わり方とか
こちらのフィードバック提案とかっていうのを
どっから投げればいいとか
その辺の窓口だったり応答性とか
っていうのも逆に気になりましたね。
エンジニアコミュニティの人たちが
実際のユーザーになるので
そのユーザーとの連携の仕方とか
サポート対応の手厚さっていうのも
気になりますね。
多分その辺も考えていると思いますし
その辺の体制を組んでいるとは思いますけど
気に入ったというところです。
続いて、What are we not trying to do?
我々がしないことっていうのを定義しますと
我々は新しいAPIを規定する
仕様作成団体になろうとするわけではないです。
あくまでサポートとかですね。
私たちは既存のAPIを改善するために
既存の仕様作成団体のメンバーとともに
働きたいと考えています。
ここは大事ですね。
我々は既存の仕様をフォークしたり
新しいバージョンを作ったりすることもありません。
我々が提案する変更については
常に既存の場ですね。
What are gRW3Cなどの上流の仕様に
組み込まれることを目標としています。
私たちはWebプラットフォームAPIの焦点を
非ブラウザーランタイムにのみ提供するように
シフトしようとするわけでもないです。
私たちはブラウザーと他のランタイムの
両方で有用で素晴らしい働きをする
APIサーフェイスをもっと見たいと思っています。
いいですね。
基本的には新たな視点を持って
いろんな提案だったりフィードバックだったり
改善の動きをしていきたいというところです。
別に新しいものを作りたいというわけではないし
既存の素晴らしいものに乗っかるというか
そこへのパラナル改善とか
今まで弱かったところの補填をするとか
そんなような感じですかね。
もちろん自分たちの提案から新しい
仕様だったり機能が加わるんだったら
それはそれでいいことだと思いますけど
いわゆる乗っ取るという意味ではないし
一緒に歩いていきたいというところが
一つですねというところでした。
続いて
Does the Windows CG operate by consensus?
W3Cはコンセンサスによって運営されているんでしょうか
というところですけど
当グループは成果物の変更について
コントリビューターの間で大まかなコンセンサスを
行うように努めています。
正式なコンセンサスではなくて
ある成果物のエディターが
その変更を取り入れる準備ができているかとか
グループから十分なサポートを得られるかどうか
というのを判断します。
グループ自体には検証に記載された
厳格なコンセンサスポリシーがあり
グループ議長がそれを監督していますよと言っています。
というところでした。
上手いことちゃんとオープンな場で議論できるとか
でもそれでいいという意識決定の方法とか
フローとかというところですかね。
準備できているしある程度の基準であったりとか
ものさしというのも一応規定はしているということですね。
そもそも海外の団体なので
12:02
国が違ったり文化も違ったり
もちろん活動する時間も違いますので
その辺はある程度決めないと
物事は進まないと思います。
まずそこから多分入ったんじゃないかなとは思いますね。
続きまして
続きましてというか次がラストですね。
Who controls the WinterCGです。
誰がWinterCGをコントロールしているのかというところですけど
WinterCGはそこで働く人々のコミュニティによってコントロールされています。
グループの議長というのは複数可能ですけど
議論を司会し提案された変更について
ご意見が得られるようにグループを導く手助けをしています。
現在グループは個人のメンバー及び以下の組織のメンバーで構成されています。
リストがあるんですけど
ブルームバーグだったり
クラウドクレアDのIgalia
ノードJS、ショピファイ、バーセルですね。
というところと組織されています。
このグループというのは
Web Platform APIをブラウザー以外で使用することに
興味を持つ人なら誰でも参加できます。
ここから参加できますので
ここっていうところにリンクが張られています。
W3Cコミュニティアンドビジネスグループっていうところですね。
がそのグループだそうです。
基本的にはW3Cコミュニティアンドビジネスグループが
基本的にはW3Cをベースな団体とかに
入っていくコミュニティとして
ジョインしていくというところですね。
もし興味のある方は入ってみてください。
もちろん海外の団体は全て英語だと思うので
そこのハードルは高いですし。
最後ですね。
W3Cメンバーであれでも必要はなくて
コミュニティグループへの参加は無料にもなりますよ。
というところでした。
もちろんW3Cメンバーになりたい方は
別になっていただいてもいいと思いますけど
そうじゃなくても無料で誰でも参加できますよ
というところがこの団体の一つのポリシーだそうですね。
というところでした。
じゃあW3Cはこんなところで一旦以上にしたいと思います。
ざっくり概要はつかめましたし
どういうことをする団体なのかっていう動きは
なんとなくつかめたので
今後も期待していきたいと思いますし
今彼らの提案だったりとか
発表っていうのも待ってみたいかなと思いました。
続きまして
クラウドフレアワーカーズの
How Worker Worksという記事を読んでいこうかなと思います。
そもそも僕クラウドフレアを全然使ったことがないので
気にはなりますけど
じゃあいきましょう。
クラウドフレアワーカーズの
How Worker Worksというところですね。
どのようにワーカーズが動いているのかというと
仕組みのお話をしていこうと思います。
クラウドフレアワーカーズは
ブラウザーやノートJSのJavaScriptと同様の動作をしますが
コードを考える上でいくつかの創意点があります。
ワーカーズランタイムというのは
基本的にChromiumやノートJSで使用されているのと同じ
V8エンジンを使用しています。
ワーカーズランタイムはほとんどのモダンブラウザで利用できる
標準的なAPIの多くも実装しています。
ブラウザー用に書かれたJavaScriptとノートJSの違いというのは
15:01
ランタイムで起こります。
ワーカーズの機能というのは個人のマシン
例えばブラウザーとかアプリケーションとか
集中型サーバーではなくて
クラウドフレアのエッジネットワークですね。
何百もの場所に分散した何千ものマシンからなる
今成長中のグローバルネットワーク上で実行されますよ
というふうに言っています。
一応そのクラウドフレアエッジネットワークという
ところのリンクも貼られています。
そういう記事のリンクが貼られているので
興味ある方はそこも読んでみてくださいということでした。
ざっくり言うと
クラウドフレアグローバルネットワークといって
マシンの数とかパフォーマンスですね。
どれくらいのスピードで物事を回収するのとか
どれくらいのデータ量を持っていますかとか
その辺のところがざっくりデータとして載っていますし
あと各リージョンですね。
リージョンごとのケーションごとのデータとかも載っています。
一応我々のところでいくと
エイジアのところですね。
エイジアを見ると
日本は大阪になるらしいですね。
東京ではなくて大阪にあるらしいですね。
というところでした。
続きまして
これらのマシンというのはそれぞれ
ワークアウトのランタイムのインスタンスをホストしており
それらのランタイムはそれぞれ何千ものユーザー定義アプリケーションを
実行することができます。
この回答ではそれらの違いのいくつか以上確認していきましょうと。
最も大きな違いは三つほどあります。
一つは分離。
二つ目にリクエストごとの計算。
そして分散実行です。
これが大きな違いだそうですね。
分離というけどアイソレートですね。
ワード的には。
それぞれリクエストさらに見ていきましょうと。
最初アイソレート分離ですね。
V8というのはアイソレートを管理するものでありますと
これはあなたのコードがアクセスできる変数と
その中で実行される安全な環境を提供する計量のコンテキストになります。
アイソレートというのはあなたの関数が実行される
サンドボックスを考えることもできますと。
ほう、サンドボックスを考えることもできます。
ちょっとねごしよう。
一つのランタイムで数百もしくは数千のアイソレートを実行でき
シームレスに切り替えることができます。
それぞれのアイソレートのメモリーは完全に分離されてますので
それぞれのコードのかけらですね。
コード編っていうのはランタイム上の他の信頼されてないコードとか
ユーザーが書いたコードから保護されてますと。
これは昨日読んだところですね。
実行中のメモリーっていうのが分離されてますと。
スレッドが分離されているのかどうか
その辺がちょっと分かるんですけど
数学のメモリーが分離されているところで
他のコードと影響することはまずないよ
というところが信頼のところですね。
またアイソレートって非常に高速に起動するようにも設計されてますと。
機能ごとに仮想マシンを作成するのではなくて
既存の環境の中にアイソレートをどんどん作っていくと。
18:01
このモデルにより仮想マシンモデルのコールドスタートっていうのが解消されますと言ってますね。
いわゆるコンテナをどんどん乱立させるわけじゃなくて
一つどーんとでっかいところにアイソレートって分離した
メモリー領域とかを作っておいて
そこでコードを走らせるようになっているそうですね。
これをV8エンジンを使えばそれが実行できるというところですね。
すると多分中ではプロセスごとに分けてんじゃないかなと思ったりしました。
では続いて読んでいきましょう。
一応この記事の中には図も載っているので
もし興味ある方はその図を見てみてください。
いわゆるユーザーコードとプロセスオーバーヘッド
プロセスでやっぱ集まるっていうところを分けてて
そこに書いてますけど
いわゆるトラディショナルアーキテクチャ
いわゆるコンテナをどんどん乱立させるような方だと
一個一個がちゃんと分離しているのは一目瞭然なんですけど
ユーザーコードに対してプロセスのオーバーヘッドが結構大きくなって
それが固まっていくと結局無駄だねっていう話になってくるんで
領域内でやったとしても
やっぱりV8のアイソレートを使えばユーザーコードを走らせて
プロセスのオーバーヘッドは一つに集約できてますし
このオーバーヘッドも小さくすることが可能だよっていう風にやってますね。
具体的に中身のソースコードは見てないから
どれだけできてるかとか実際の数字も取ってないかわからないですけど
一応V8アイソレートを使えばそれができてるってことでした。
では続いて各言語ランタイムのインスタンスを実行する
コンテナ化されたプロセスを使用する他のサーバーレスプロバイダーとは異なり
主語が長くてちょっと理解します。
各言語ランタイムのインスタンスを実行する
コンテナ化されたプロセスを使用する他のサーバーレスプロバイダー
要は他のサーバーレスプロバイダーとは異なっているってことですね。
ワーカーズっていうのはJavaScriptランタイムのオーバーヘッドを
エッジコンテナの開始に一度だけ支払うの。
さっきの図の通りですね。
オーバーヘッド一回だけ支払ってしまう。
ワーカーズプロセスっていうのはワーカーズ関数を呼び出しごとに
アイソレートを作成することでほとんど個別のオーバーヘッドなしに
本質的に無限のスクリプトを実行することができます。
無限といってもサーバーのコストの限界点までってところですね。
そこまでだったら無限にスクリプトを実行できますよってことですね。
任意のアイソレートっていうのはコンテナや仮想マシン調のノードプロセスよりも
100倍ほど早く起動することができます。
ほんまかよ。
クラウドフラってエッジサーバーですよね。
エッジサーバーがコンテナや仮想マシン上のノードプロセスよりも
100倍早く起動するってのはそこそこ。
それは正しいですね。
なるほど。
でも100倍ほど早くなるってのはすごいですね。
これはみんなちょっと注目するし魅力あるわ。
注目すべきは起動時のアイソレートが消費するメモリーが
桁違いに少ないことですってところですね。
まあそりゃコンテナも起動しないんだからそりゃ早いですよね。
仮想マシン立てないんですからね。
使えないしメモリーも少ないっていうところで。
21:00
それは使わない手はないという感じがしましたね。
続いて、あるとあるアイソレートはそれ自身のスコープを持ちますけど
そのアイソレートは必ずしも長寿命でもありません。
多くの理由によってアイソレートはスピンダウンして
追い出される可能性もあります。
マシンのリソース制限ですね。
その理由のいくつか見ていくんですけど
アイソレートのリソース制限っていうのがまず一つあがると。
続いては怪しいスクリプトですね。
アイソレートのサンドボックスから出ようとしてるような動きをする
スクリプトとかがあればそれも除外されるというか
スピンダウンされる、追い出されるかもしれないと言ってますね。
個々のリソースの制限ですね。
単純にリソースのリミットが来たらというところでした。
1個目のマシンのリソースの話ともやっぱり繋がってくるので
結局一緒かなと思います。
リソースか怪しいスクリプトかっていうところで
追い出しが行われる可能性があるよということでした。
このため一般的にはこの不足の事態を考慮しない限りは
グローバルスコープにミュータブルステートを保存しないことを
お勧めしますと。
JSなんでそもそもスコープの話は絶対みんなやりますし
グローバルスコープに変更可能な状態っていうのを
持たないほうがいいよっていう話はしてますね。
やっぱりグローバルなところをやってると
クラウドフレアワーカーズはもしかしたら弾くかもしれない
ということですね。
もしクラウドフレアがワーカーズランタイムで
どのようにセキュリティを扱ってるかっていうところに
興味があるのであれば、アイソレートとセキュリティの
関係やスペクトラスレッドマイグレーションっていう
ところの記事があるのでそこを見てもらってもいいんじゃないの
っていうふうなお話でした。
それもこのクラウドフレアドックスの中にある記事かな。
あ、ですね。
セキュリティモデルっていう記事があるのでその辺を見て
もらってもいいんじゃないかというところでした。
続きましてコンピュートパーリクエストですね。
リクエストごとの処理っていうところですね。
ほとんどのワーカーズスクリプトっていうのは
デフォルトのワーカーズフローを変形したものになりますよ
って言ってますね。
一応サンプルコードが載っててちょっと音速なので
理解できるかわからないですけどなんかふーんって
アドイベントリスナーで第一歴数フェッチですね。
イベントリスナーでフェッチをコールしますと。
第二歴数はコールバック関数ですね。
引き継いにイベントオブジェクトを受け取って
event.respondwithっていうところですね。
respondwithをメソッドをコールしてハンドルリクエスト
イベントリクエストでガーッと処理をしていくと。
その下にasyncファンクションでそのハンドルリクエスト
っていうところですね。
リクエストを引き継いに受け取りますと。
リターンでニューレスポンスを返したり出ます
という感じの処理ですね。
その中に一応httpのステータスコールですね。
ステータス200みたいなのをうまくいったら返してください
みたいな。本当に既存のJavaScriptをそのまま書ける
24:01
っていうところが面白いなってことですね。
昨日読んでいた水地さんの記事の中には
スタートの方でファストリーですね。
ファストリーさんのCDNの使い方とか
エッジでの処理の書き方みたいなところの説明も
あったんですけど、あっちだとファストリーさん
固有の言語みたいなのがあって、それを覚えて
その中で処理を書いていかなきゃいけないという
ところがすごくロックインしてしまうので嫌だな
という話だったんですけど、クラウドフレアワーカーズ
のほうは普通にJavaScriptを書ける、やっぱり
V8エンジンっていうのがベースになっているので
そういうのしやすさっていうのも大きいなと
今見てて思いました。では続きまして読んでいきます。
あなたの例えばサブドメインとして
nantara.workers.devっていうサブドメインですね。
もしくはクラウドフレア管理するドメインへの
リクエストがクラウドフレアのランタイムの
いずれかによって受信された場合ですね。
その場合、ワーカーズスクリプトっていうのは
スクリプトで定義されたイベントハンドラーへ
そこからその場でレスポンスを計算したり
フェッチを使って他のサーバーに呼び出したりすることで
レスポンスを生成することができますと。
レスポンスウィズっていうコールバックアンセス
の呼び出しポイントに到達するために必要な
CPUサイクルというのはすべて計算時間に寄与しますと。
例えばセットインターバルのタイムアウトというのは
待機中のCPUサイクルというのを消費しないようになっていると。
これもすごいですね。セットインターバルのタイムアウトを
消費しないんですね。これすごいな。どうやってんだろう。
中の実装やっぱり気になりますね。
ラストですね。最後、ディストリビュート・エグゼキューション
分散実行ですね。
アイソレートっていうのは弾力性があってリクエストの間は
継続的に利用可能ですけど、まれにアイソレートが
立ち切れになってしまう可能性もありますと。
スクリプトが公式な限界に達したときに、あるいはリクエストが
実行されているマシンのリソースが特別に厳しい状況になってしまったとき
ですね。ランタイムってのはイベントが適切に解決された後
選択的にアイソレートを立ち抜かせるでしょうと。
選択的なんですね。ってことはいきなりガッと決められたルールとかで
ガツンとやっちゃいますってわけじゃなくて
こちらがある程度制御とか命令をして
その命令に実行されたものが
立ち抜けを食らうんでしょうね。
やったことないから分かるんですけど、その辺の設定があるんだったら
そこまでコントローラブルにアイソレートのところを
実行できる。かなりおいしい話だと思いましたね。
他のすべてのJavaScriptプラットフォームと同様に
単一のワーカーズインスタンスっていうのは
シングルスレッドのイベントループで同時リクエストを含む
複数のリクエストを処理することができます。
単一のワーカーズインスタンスなのにシングルスレッドのイベントループで
同時リクエストを含む複数のリクエストを処理することができる。
つまり、あるリクエストを処理している間に他のリクエストが来た場合
フェッチなどの非同期タスクが待機中に
他のリクエストが処理されるかもしれない、またはされないかもしれない
ということだと言ってますね。されない可能性もありますけど
27:01
処理することはできるんですね。
他のリクエストが来たときに
フェッチとかの非同期タスクの待機中に他のリクエストが処理
される可能性もあるんですね。
するしないをはっきりしてくれたほうが嬉しいですけど
されないんだったらもう一回僕らもコールします。
それができちゃうのもすごいですね。
シングルストレートですよね。
2つのユーザーリクエストがワーカーの同じインスタンス
または異なるインスタンスにルーティングされる保証がないため
グローバルステートを使用または変更しないことを
お勧めしますよと言ってました。ここは使い方に注意が必要です。
裏の方ですね。中身を見たところでいくと結局
アイゾレットというのが
メモリー領域というのははっきり分断しているというところが
やっぱり大きなポイントで、これがあるから
もしかして複数のリクエストが来ても何とか
処理できる可能性があるというところなんじゃないかなと
今見てて思いました。ただでもリクエストごとに
普通に考えたらスレッドが立ち上がると思うので
シングルストレートの中で複数処理同時に走らせること
ではできるのかな。基本的にノードJSが動くという
ことでいわゆる非同期処理だと思うので
メインストレートの中でどんどん走らせるという
ことだったらできると思いますけど
それがEdgeサーバーの中でも同じようなことができる
つまりEdgeサーバーは本当にノードJSとしてアプリケーションが
動く可能性が大いにあるというか動かすことができるんでしょうね
というのがやっぱり背景としてあってそれが大きいんだろうな
というふうに感じましたね。ということで
ざっくりですけど今のでHow Workers Worksのところですね
記事の中身は今ので一緒になります
一応Related Resourcesというところでフェッチイベントとか
リクエストコンテンツ、あとランタイムリミテーションという
別の記事のリンクがあるのでそこも関連しているので
興味あったら見てみてくださいというところでした
この記事実は4時間前に更新されてますので
しっかりメンテナンスもしてますし
クラウドフレアも常にやっぱり機能改善とか
どんどん発展とかを進めているというところがあるそうですね
なんとなくそういうのが見受けられましたので
このままクラウドフレアちょっと僕は
ついづいしていこうかなと思います
というところで一旦今日の朝方は30分過ぎましたので以上にしたいなと思います
はい
明日も引き続きクラウドフレアの記事を読んでいきたいんですけど
そればっかり読んでいくと皆さんの学びにもならないので
またいつも通りですねWeekly FrontendのかもしくはJ3インフォの
記事で1回とりあえずフロントエンド周りのニュースを
ザーッと眺めてそこから余った時間でまたクラウドフレアの
記事を読んでいこうかなと思ってますので
ぜひ皆さんもゆるりと参加いただければなと思います
では1週間中日水曜日ですね
今日もまた1日頑張って織り返していくんですけど
お疲れ様でした
