🍃このブログは移転しました。
3秒後、自動的に移動します・・・。

Cloudflare Workersを軽く試した感想

Cloudflare Workers docs

巷で話題のエッジワーカーというやつ。

お仕事で使えるかもしれないというわけで、Docsを一通り読んでみて、ちょっとしたコードをデプロイしてみたところまでの感想。

Docsを読んでの学び

コールドスタートがない

AWSやらGCPのそれと違って、ランタイムごとにコンテナを〜という構造ではないから。

V8のIsolateなる機能を使って、基本的に立ちっぱのホストの上で、ランタイムだけを起動できるとのこと。

How Workers works · Cloudflare Workers docs

なので、たまーに動かすコードでも実行が速いというわけ。

リージョン: 地球

普通にそう書いてあってカッコいい・・ってなった。

実行時間の制限がない

時間に関する制限は、CPU時間だけ。

Limits · Cloudflare Workers docs

Netlify functionsやLambdaで気軽にできなかった、

  • Slack Botのリクエスト受付、まずはレスポンス返す
  • からの、時間かかる本処理の結果を改めて送信

みたいなことが、単独でできる。

Slack Botは、チュートリアルでもカバーされててGitHubにコードもある。

https://github.com/signalnerve/workers-slack-bot

そして実行時間で課金されるわけでもないっていうのがポイント。

用途によってはCPU時間がオーバーすることもあるかもしれんけど、ほとんどの一般人は困らない感じよね。

Cronでの定期実行もできる

さすが〜欲しい機能わかってる〜って感じ。

この場合は、`addEventListener("fetch")`ではなく、`addEventListener("scheduled")`でハンドラを定義する。

Cron Triggers · Cloudflare Workers docs

HTTPしか話せない

通信プロトコルとして。

つまり、MySQLやMongoDBやらを簡単に読みに行けないし、SMTPやらUDPやらも、もちろん使えない。

いわゆる`ServiceWorkerGlobalScope`でコード書いてるという認識がなくて、単なるFaaS代替と捉えてると、思ってるのと違う・・ってなりそう。

そういうデザインなので仕方がない気はするけど、実用性という意味では割と大きな制限かなーと思う。(DBの前段にGraphQL置くか〜〜〜ってなる)

Node.jsではない

つまり、`EventEmitter`とか`child_process`とか`Buffer`とか`crypto`とか、そういうのはない。

WHATWG Streamsとか、Web Cryptoとかそういうのはある。(これも`ServiceWorker`なので・・と思えばまあ)

`npm`から持ってきたライブラリがそのままでは動かない、みたいなのはよくありそうで、よくわかってないと誤解されそう。

FaaS代替としても使える

まあ本来の用途ではないけど、`workers_dev`の機能とかもあるし、それなりに想定されたユースケースなんやろうなと。

上述の通りNodeで動くものが100%動くわけではないってことさえ注意すれば、ちょっとしたAPIをさくっとデプロイできるのは便利。

ただやはり本旨としての、「CDNに本来は飛ぶはずのリクエストをinterceptして、HTMLをリライトして返す」みたいなことに使ってみたいという欲がでるな・・。

Rewrite links · Cloudflare Workers docs

(FaaS代替として)コードを書いてみて

wanglerがよくできてる

WorkerをデプロイするためのCLIが`wrangler`というコマンドで、これがよくできてるなと思った。

`webpack`が同梱されてて、`wrangler publish`ってするだけで、自動でprodビルドしてデプロイしてくれる便利・・!
単にFaaS代替として使ううちは、自分でビルドしたい気持ちもそんなに出てこないので、`sls`の代わりに使える。

あとは`wrangler secret put MY_SECRET_KEY`ってすると、環境変数的な値を埋め込めたりするのも、GUIから設定したくない派としては嬉しいポイント。

wrangler dev惜しい

`wrangler dev`という、仮の実行環境にコードをデプロイして、それを透過的に`localhost`からアクセスする機能がある。

(実際にデプロイしてるということに気づかず、ローカルで完結してるっていう先入観があると、即リロードしても反映されてないあれ?ってなるはず)

`console.log()`でデバッグできるのはすごい便利な反面、ファイルの増減で割とカジュアルにcrashしたりする感じがある・・。

シンプルゆえに

そもそもの発端がFaaS代替ではなく、CDN前のServiceWorkerなメンタルモデルなので、そこに慣れてないといろいろハマるかなーと思った。

  • `Response`生成したら`Request`の中身さわれなくなるとか
  • `waitUntil()`、`passThroughOnException()` の使い方いまいちわからんとか

あとは、リクエストをパースするコードも用意されてないので、ルーターみたいなのが欲しくなるまでに時間はかからないと思う。

観測範囲だとやはり https://github.com/lukeed/worktop 推しかな・・?

まとめ

あくまでFaaS代替としては、

  • Cons: HTTPの縛り
  • Cons: Nodeではない
  • Pros: コールドスタートがない
  • Pros: リージョンの概念がなく地球のどこからでも速い

ってあたりが大きな差異かな?

ただロギングの仕組みすらもなかったりするので、単機能な用途ならまだしも、あれこれやる必要がある場合、Edgeでそれをやる意義を見いだせない場合は、そんなに使い勝手がいいわけではないのかなーと。

あとはCDNの手前にいることを活かした使い方と、Cache/KV/DOまわりを使った独創性のあるアーキテクチャを試してみたい。なんか丁度いい案件ないかな〜。