Cloudflare Worker使ってみた
リリースを見た時「あーすごいなーこの発想」と思って、これは使ってみなきゃということでやってみた。
Cloudflare Workerとは
Cloudflare CDNのエッジで動作させるWorkerプログラムで、面白いのはService Worker、つまりJavaScriptで書けること。
そもそもService Worker自体がブラウザのリクエスト・レスポンスをフックして処理するものなので、リクエストとレスポンスが対になるならEdgeサーバで使おうぜっていう発想がすごい。
詳しくは他の人も書いてるのでそっちを参照のこと。
AWS LambdaのGatewayとして使ってみる
WorkerをGatewayとして、AWSのLambda Functionをコールしてその出力をレスポンスとして返すGatewayを作ってみた。
Lambdaを使う機会は増えてきてると思うんだけど、外からコールする時はAPI Gatewayが必要で、Go用のServerless Frammework作ったでも書いたけどAPI Gatewayの設定はかなり面倒。 Lambda Proxy統合機能ができて少しやりやすくはなってるけどそれでもポチポチ作るかSDKで自動化しないとしんどい。
じゃあCloudflare WorkerからコールするURLを生成してfetchすればAPI Gatewayいらんよねってやっている人がいて自分もやってみた。
現状は一枚のスクリプトでやる必要がある（playgroundだからかな）みたいで、browserifyでバンドルしてAWSのアクセスキーを埋め込んで実行する。 browserifyが楽で使ったけどwebpackでもできるはず。
生成されたworker.jsを貼り付けてTestingのところに関数名をパスで渡すと結果が得られる。API Gatewayはいらんかったんや…
サンプルではそのままレスポンスを戻してるけど、関数によってCache-Controlを付けたり制御が挟めるのもAPI Gatewayよりも自由度が高い。
playgroundレベルなのでパフォーマンスがどうとかは計測できていない。Productionで使うならもうちょっと踏み込まないといけない。 それからモジュールシステムは欲しいな…無理かな…
とはいえ、気軽にLambda over HTTPができるのは便利じゃないかな。
まとめ
業務ではfastlyを使っていてfastlyも好きなプロダクトなんだけど、やっぱりVCLのつらさはあって、JavaScriptで書けるなら嬉しいよね。 これからキャッシュとかもやっていくみたいな話を聞いたので、置き換えられる部分はCloudflareにしても良いんじゃないかなぁ。
とりあえずCDN通して、動的な部分はWorkerでという導入フローになるのかな。 いずれにせよ自分でサービス何かやるなら是非使ってみたいと思っている。
現場からは以上です。