Cloudflare社は、定期的に「なんたらWeek」って感じでまとめてアップデートを発表する取り組みをやってるっぽく、今回のテーマはフルスタック!
なんでもかんでもCloudflareでできるようにするよ!という強い意志を感じる発表たちだった。
今回は実験的にTwitterでもまとめて流してたけど、やっぱりブログにまとめるほうがしっくりくるなってことで、改めて。
- https://twitter.com/leader22/status/1460451057109127169
- https://twitter.com/leader22/status/1460772775010791430
- https://twitter.com/leader22/status/1461158193631936512
- https://twitter.com/leader22/status/1461592966682660864
- https://twitter.com/leader22/status/1461725844355698693
ここでのまとめは発表順ではなく、カテゴリごとになってます。
Workers
MongoDB Atlas and Prisma support
Workers adds support for two modern data platforms: MongoDB Atlas and Prisma
タイトルだけ見たときは、ついにMongoの公式サポートきたか?!って思ったけど、よくよく読んでみるとそうではなかった。
MongoDBならばRealm、PrismaならばPrisma Data Proxyを使って、HTTPでアクセスできる口を自分で用意すれば、そこにWorkerからつなげるよって話。
これは別に前からできてたことなので、なぜ今さら?という感じではあった。単にベンダーとしてパートナーになったよっていう報告かなーと。
Durable Objects: GA
ベータだったDOが、ついに一般利用できるようになった!
ただ未だにどう活用していけばいいのかわかってないので、これでユースケースがどんどん発掘されるようになったらいいな・・くらいの気持ち。
Database Connector
これまで、Cloudflare Workersを使う上での大きな制約として、プロトコルがHTTPしか使えないというものがあった。
そのため、TCPでの接続を要求するだいたいのDBが使えなくて、どうしても連携したければ自分でHTTPを話せる層を用意しないといけなかったりと地味に不便だった。
それをなんとかするための方法を編み出したので紹介するよ!っていう話。
Cloudflareは既に`cloudflared`っていうネットワークトンネルを作る仕組みを持ってて、それを使うことでTCP over WebSocketができる、と。なのでそのトンネル経由でDBにつないで、Workerからは専用のクラスを使えば、まるでHTTPからDBを扱える!
ただ今のところこの作戦は、自分たちのDBサーバーに自分たちで`cloudflared`を常駐させる必要があって、まだ道半ばといったところ。
将来的にはこれをCloudflare側でホストすることも考えてて、その検証を手伝ってくれるパートナーを探してるよとのこと。
ちなみに、Workerで利用できる専用のクラスはドライバって呼ばれてて、Denoのコードを拝借してカスタマイズしたらしい。
PostgresとMySQLの2つがサンプルとして上がってる。
https://github.com/cloudflare/worker-template-postgres/tree/master/src/driver/postgres
https://github.com/cloudflare/worker-template-mysql/tree/master/src/driver/mysql
コレも今はコピペして使ってねって状態。
Socket Workers
やっぱみんなTCP使いたいですよね・・となるときっとUDPも・・というわけで。
いっそのことWorkerから直で使えるようにしちゃう?ってことで動き出したのが、我らが`@jasnell`御大・・・!
// use TCP const socket = new Socket({ remote: { address: '123.123.123.123', port: 1234 }, }); for await (const chunk of socket.readable) { console.log(chunk); } // use UDP const socket = new Socket({ type: 'udp', remote: { address: '123.123.123.123', port: 1234 }, }); const enc = new TextEncoder(); const writer = socket.writable.getWriter(); await writer.write(enc.encode('hello world')); await writer.close();
ってな具合に、使えるようにしようと思っているとのこと。
で、こういう実装は既にNode.jsにもあるし、Denoにもある。
またCFWで独自実装することもできるけど、Webとしては標準APIになってるほうが嬉しい。
ので、そういう標準化もあわせてやっていくそうです。(さすが!すごい!)
現在のドラフトはこちらに公開されてて、フィードバック募集中とのこと。
これが実装されて、各DBベンダーがドライバのライブラリを公開し、我々がユーザーランドでデータを手にできるのは、いったいいつの日になるだろうか・・・!
Services over Workers
Introducing Services: Build Composable, Distributed Applications on Cloudflare Workers
Workerの上位概念として、Serviceというレイヤーが誕生した!
構成要素をざっくり表すと、今まではこう。
- Worker A(for prod) - Bindings(KV, DO, SECRETS, ENV) - Worker A(for dev) - Worker B(for prod)
これが、こうなる。
- Service A - env: prod - Worker - Bindings - env: dev - Service B
ってな感じで、Workerをそのまま作るというより、Serviceをまず作るとその中にWorkerがある、みたいになった。
既存のWorkerたちは、envを1つだけ持つServiceとして移行されてて、そういう意味では何も変わらない。
envはそれぞれでバージョニングされて、ロールバックもできるし、特定のenvを別のenvにコピーしたりもできる。
というのは、現時点でもできるようになってること。
ここからはまだ未実装やけど、この先に予定されてるやつ。
なんと、Serviceから別のServiceを呼べるようになる!
現状、Workerから別のWorkerを呼ぶのはストレートにはできないので、それができるようになるのはアツい。
Cloudflare Workersで、Workerから別のWorkerを呼びたい - console.lealog();
そして、Service間の通信は同じCDNエッジで行われるがゆえに、いわゆるMicro Sercvicesにありがちな問題だったネットワーキングのコストを0にできる、と!
これ、認証用のServiceとかロギング用のServiceとか作っておけば、似たようなコードが重複することもなくなって超絶便利ってことなんよね〜〜というわけで、個人的には激アツな発表だった。
Modules Worker format
Workerのコードの書き方として、今までもこの2つがあった。
- `addEventListener("fetch")`
- Service Workerライクなフォーマット
- `export default { fetch() {} }`
- ESMの使えるフォーマット
で、後者のやつは長らくExperimentalな感じやったけど、晴れて公式な書き方に。
ESMで書く場合は、もちろん`import`がそのまま使えるので、ビルドせずにWorkerのコードを書くこともできる。
が、インターネットにあるURLを`import`できるわけではないので、まあビルドする事実に変わりはない感じ。
ESMフォーマットで書く場合、`wrangler.toml`にはこう書く必要がある。
type = "javascript" [build.upload] format = "modules" dir = "./src" main = "./worker.js" # becomes "./src/worker.js" [[build.upload.rules]] type = "ESModule" globs = ["**/*.js"] # Uncomment if you have a build script. # [build] # command = "npm run build"
SWのフォーマットがサポートされなくなるわけではないので、そこはご心配なくとのこと。
Wrangler CLI v2
wrangler 2.0 — a new developer experience for Cloudflare Workers
CLIツール`wrangler`のメジャーバージョンアップのお知らせ。(今はまだベータ)
0 configで使えるようになったのと、ChromeのDevTools連携が入ってデバッグがしやすくなった。
あとはローカルで開発するときには、MiniflareっていうNode.jsで書かれたCloudflare Workersのエミュレータを使うことがデファクトになってたけど、今回それがついに内部的に取り込まれた。
Miniflare自体がCloudflare傘下のリポジトリに入った時点でそういう予感はあったけども。
Miniflareの作者である`@_mrbbot`氏、いつの間にかCloudflareの人になってる?!って思ったら、どうやらインターン中らしい。
インターンってことは・・若者ってことやん・・マジすげーわ・・・。
ちなみに、`wrangler`のv1はRustで書かれてたけど、v2になるにあたり、TypeScriptになってました。
また今度コード読んでみよ。
Workers Unbound updates
Workers, Now Even More Unbound: 15 Minutes, 100 Scripts, and No Egress Fees
Cloudflare Workersの有料プランであるUnboundについて。
- AWSだと割と高くつくらしいEgress(転送量)にお金がかからなくなった
- CPU時間の上限が15分までに伸びた
- デプロイできるWorkerの数が100まで増えた
とのことで、利用者としてはただただ嬉しい話。
AWSのS3でそれなりにかかるコストがCloudflareのR2だとかからないとか、Egressフリーはこれからもやっていくとのこと。(すごい)
あとは、Workerとしてデプロイできるコードのサイズも拡張する予定しているとのこと。WASMとかじゃんじゃん使えるように。
これは申請してもらえれば今からでも拡張してくれるらしい。
その勢いでサブリクエスト数も拡張してくれるようになりませんかね・・・!
Native support for Stripe JS SDK
Announcing native support for Stripe’s JavaScript SDK in Cloudflare Workers
決済サービスのStripeのSDKは、ずっとNode.js用のパッケージだったので、Workerでは使えなかった。が、それが今回使えるようになった!
って書いてあって、もしやNodeのAPIが使えるようになったんか?!って思ったけど、これもそうではなかった。(初日のMongoのやつといい、ちょっと表現がアレではってなった)
中の人の働きかけもあって(?)、StripeのSDK側に修正がはいって、利用環境ごとに`fetch`の実装を変えられるようになった結果、Workersでも使えるようになったって話。
Pages
Pages Functions
単なる静的サイトホスティングサービスだったPagesが、今回の機能追加でAPIまで置けるようになり、フルスタックなプラットフォームに進化した!
`functions`ディレクトリにファイルベースのルーティングでコードを置くと、それがAPIになるし、ミドルウェアの機構もある。
裏で動くAPIがCloudflare Workersってところがポイントで、KVやDOを使いつつエッジベースな構成が引き続き組める。
WorkersはPagesのお供としてシームレスに用意されるので、Workers側のダッシュボードになんか増えたりはしない。
今はまだオープンベータで、Functionsの実行回数に100000/日の制限がある。(これはダッシュボードからもう見れる)
https://developers.cloudflare.com/pages/platform/functions#pricing-and-limits
APIが置けるようになったってことは、SSRするぜ系のフレームワークがそのまま置けるようになるってこと。
SvelteKitは既にアダプターの実装を済ませてて、今日からもう使える。
https://github.com/sveltejs/kit/tree/master/packages/adapter-cloudflare
Nextとか他のフレームワークの対応も進めていきたいとのこと。
そういう意味でVercel以外の選択肢ができたのは、業界的にもよいのかもしれない。
こういうフレームワーク系は、Pagesが想定する`functions`ディレクトリとかのお作法に乗るのが難しい場合もあるので、ルートに`_worker.js`を置けば、それが使われるようにもできる。上述のSvelteKitのアダプターもそういう実装になってた。
というわけで、Workersをそのまま使う人は引き続き使うけど、多くの人にとって嬉しいちょっとだけAPI足したいみたいな用途をカバーしてるのは、上手いやり方やなーって思った。
Images
AVIF supports
Cloudflare Images introduces AVIF, Blur and Bundle with Stream
Cloudflare ImagesでもAVIFが使えるようになった。
というか、Imagesを利用してれば勝手に対応される。
そのほかBlur加工の指定もURLのパラメータから簡単にできるように。
Others
Developer Expert Program
Cloudflareは開発者と一緒になって高速なサイクルでサービスを開発していきたいんじゃよって話。
エキスパート制度に登録すると、中の人とより近い距離で接することができて、お互いにWIN-WINだと思うので、みんなぜひ登録してねとのこと。
気にはなるけど、もう少し詳細が知りたいです!
Response headers modification
サイト単位でまとめて有効可できるレスポンスヘッダのフィルタ。
いちいちWorkerを立ててプロキシしなくてよいので、設定する側としてはすごく楽になったかも。
Network Performance Updates
世界一速いネットワークを目指してるという話。
パフォーマンス測定は定期的にやってきてて、前回はAWSのLambda Edgeより210%速いことを発表してた。
今回はFastlyのCompute@Edgeと比較して、Cloudflare Workersのほうが196%速かったことを報告するよ、と。(ここで公開されてたのはTTFBの速さ)
というように、世界中で速さを追求するために、こういうことをしてましたっていうレポート記事。
地道な努力でありすごいな・・って感想しかなかった。
おわりに
ベンダーロックインとかマルチクラウドどうすんねん的な話はさておき一蓮托生で使えるなら、ほんと全方位の便利プラットフォームになってきたなーって感じ。そして速い、速いは正義。
Cloudflareに乗り換えたらこんなにも速くなったぜ!みたいなことが言える仕事してみたいな・・。
ちなみにこのXxxWeek的な取り組み、2021年内にまだあと1回あるらしいですよ。