バグ発見から学ぶ：Cloudflare Workers+Hono で SESAME API を最適化

SESAME に関する記事はこれが 3 本目かもしれない。 今回、SESAME 関連の自前開発をしてて、Cloudflare Workers のバグを発見したので、その顛末を綴っていこう。

SESAME 操作環境遷移

以前の記事の通り、自分の SESAME 操作環境は下記のように遷移していった。

1. Google App Script + IFTTT
2. Google App Script + MacroDroid
3. Cloudflare Workers + MacroDroid(And ショートカット)

まず、GAS+IFTTT の王道の組み合わせだが、以下の不満点があった。

• IFTTT の反応がゴミ

自分が帰宅範囲内に入っても全然動作しないというやる気の無さっぷりにキレてしまった。 そうして、ネットの海を徘徊して見つけたのが、MacroDroid。 GAS+MacroDroid の組み合わせは、しばらくは不満がなかったのだが、これもまたイライラする要素があった。 それは

• GAS の起動がゴミ

GAS を使ったことがある人なら分かるが、GAS は起動速度がとんでもなく遅い。 Cold start だと平均 9 秒～ 11 秒くらい掛かる。 そもそも、GAS をサーバレス・アーキテクチャとして使うなという話ではあるが、この起動の微妙な遅さのせいで、帰宅してから数秒のタイムラグがあり、キレてしまった。

Cloudflare Workers + Hono に出会う

そんなさなか、ひょんな事から Cloudflare Workers+Hono の案件をもらい、実装する事でその汎用性の高さに気がついた。 まあ、この Cloudflare Workers を実装するきっかけになったのも GAS の案件で、死ぬほど GAS の起動が遅いからどうにかしてくれーという話に対応するためであった。 GAS はデータベース的に使うと便利（コンピュータにそこまで詳しくない人でもデータ入力ができる）なのだが、その分高速性は犠牲にされている。 1 分 1 秒が貴重な現代では、10 秒のコールドスタートははっきり言って時間の無駄。 Cloudflare Workers はその点 1 秒くらいで結果が返ってくるからマジでヤバい。 Serverless とはこういう事を言うんだと体感できるほどの早さ。しかも、ある程度までのリクエストなら無料で使える。 Web 関連で遊んでいる人は、無料の API サーバとして活用できると思う。

そして、その Cloudflare Workers と相性が良いのが Hono。

Hono + Cloudflare Workers で REST API を作ってみよう

の記事が、順に実装していく記事でとても分かりやすかった。このコードを丸パクリすれば、GET、POST、PUT、DELETE を持った REST API サーバを簡単に生やすことができる。 Hono のシンプルさと汎用性の高さは凄い。

SESAME API の移植とソースコードの公開

この体験に味をしめて、ついでに SESAME の移植もするかーと思い立って、昨日（2023/11/17）にゴリゴリとコードを書いて、サクッとコード公開を決めた。

先に挙げた記事を参考にざーっとコードを書きつつ、以前のコードから移植を実行。 GAS 独特のコードを根こそぎ捨てて、Web Standard に沿ったシンプルなコードに仕上がったと思う。 まあ、書いてる途中はぐちゃぐちゃだったけれど。

実はバグがまだあるのだが、試してみたいという方は README に沿って環境構築していただければ一瞬で公開できると思う。 15 分くらいで行けるんじゃないかな。

バグ発見

実はこのコード致命的なバグを抱えていて、history 部分のエンコードが上手く行かないらしく、文字化けして出てきてしまう。 という事をつぶやいたら、ゆーすけべさんからリプライが来て、最終的にIssueを立てるまでに至った。

たった 2 日の出来事である。

Issue ページを見てもらうと分かるが、誰が施錠/解錠したかのところが綺麗に文字化けしてる。 最初は、ファイルエンコーディングが間違ってたんじゃないかとか、base64 変換が失敗してるんじゃないかとか、JSON.stringify がバグってるんじゃないかと色々試したんだけれど、どうもそこが原因では無いっぽい。 fetch 関数を nodejs で直で叩くコードを実行して、初めて Hono 内部の fetch でコケている事が分かった。 原因は Hono ではなく、Cloudflare Workers の fetchだという所まで突き止めたが、そこから先は実質的に fetch のコードを読み解くのに近いので、諦めた。 僕の能力が足りてない証拠です、ハイ。 一応、Miniflare のバグっぽいなという所までは追えたので、そこに Issue を立てて終了。 これでバグが直ったら、世界貢献した事になる、多分。 どれだけの人に恩恵が発生するのかは、疑問の余地がある。

ショートカットとオートメーション

今回、iOS 側でも鍵の開けしめ出来ないかなという事で、初めてショートカットとオートメーションを使ってみることにした。 ショートカットで、施錠/解錠を作成し、WiFi の OFF でその施錠のショートカットをキックするという形式にした。 POST 関数をショートカットで作るのは簡単で、

アクションを追加→Web→URLの内容を取得

を選び、そこに API の URL とパラメータを記入すれば良い。 今回、自分が作ったケースだと

• URL:https://cf-sesame-open.XXXXXXX.workers.dev/api/sesame/lock
• 方法:POST
• 本文を要求:JSON
• テキストを追加 → キー:password 、テキスト:作成したパスワード

のような設定をしている。

ちなみに、WiFi の ON/OFF のオートメーションが使えるのはiOS17以降なので、iOS17 未満の人はアップグレード推奨。 WiFi のオートメーションは、ショートカット作成に比べて遥かに簡単なので、割愛する。

実地テストを行った結果、自宅のWiFi ONでの解錠が厳しそうだったので、解錠に関しては、ショートカットをホーム画面に追加することで対応。 ジオフェンスがオートメーションの中にあるので、そっちを使ったほうが良いかもしれない。 自分のiPhoneは馬鹿で、自宅の位置を取得できなかったので、こっちは諦めた。 もっと良い方法を思いついたらまた記事にしたいと思う。

完走した感想と、GAS 高速化の裏技

以前の GAS コードでも悪くはないけれども、起動時間 1 秒の世界を体験するともう戻れない。 10 倍だよ、10 倍。

まあ、GAS も一旦起動しちゃえば 3 秒とか 4 秒で結果が戻ってくるので別に悪くないんだけれど、そこはもうケースバイケース。 トリガー使ってずっと起動状態を作っておけば Cold start は 7 秒ぐらいに縮まるんだけれど、リソースの無駄だし、効果が薄いので、やる意味が無い。 見た目上の起動を早くすればいいので、一番重要な情報を Cloudflare Workers で表示するようにして、その裏側で、GAS をキック。 ユーザが画面操作している間に、GAS の Cold start が終わっていればユーザ体験は損なわれない。

個人的には、全てのデータを Cloudflare Workers 上（KV や D1）に置きたいが、そうするとユーザさん側でのデータ追加、更新、削除が簡単に出来なくなるので、この辺は調整が必要。 自分は、一部のデータのみを Cloudflare Workers 上において、それを別画面で perge する形にして提供した。 データ入力後、ボタンを押したら Cloudflare Workers とシンクロするようにしている。