スキップしてメイン コンテンツに移動

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

バグ発見から学ぶ：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 とパラメータを記入すれば良い。 今回、自分が作ったケースだと

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

ちなみに、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 とシンクロするようにしている。

ラベル:

コメント

コメントを投稿

このブログの人気の投稿

EFIブートローダを移動した話

EFIブートローダを移動した HX90に環境を整え終わってから、アホな事をしたので、その記録を残す。 SSD:　Cドライブ SSD:　Dドライブ(データストレージ用) + ESP※ SSD:　Eドライブ(データストレージ用) ※ESP(EFI System Partition) インストールした時、こんな構成だった。 ESPがDドライブにあるのが気持ち悪かったので、これを削除した。 そしたら、BIOS画面が出るだけになり、Windowsが起動しなくなった。 移動手順 この時の自分はMBRをふっ飛ばした時と同じ現象だと思ったので、MBRというキーワードで検索したが、今はEFIブートローダーと呼んでいるらしい。 【Win10】任意のディスクにEFIブートローダをインストールする 色々検索した結果この記事が参考になった。 Diskpartを使って、パーティションを新たに分割し、bcdbootを実行して、無事に事なきを得た。 パーティションの分割はこんな感じ Diskpart Select volume 0 shrink desired = 200 Select disk 0 Create partition EFI size=200 Format quick fs=fat32 label="ESP" Assign letter=P exit EFIブートローダーのインストールはこんな感じ bcdboot C:\Windows /s P: /f UEFI ちなみに、自分の環境だけの問題なのだが、コマンドラインで、「\」を入力するのができなかった。我が家のキーボードはHHKBだけなので、日本語配列を無理やり適用されると、バックスラッシュが入力できないという不具合が生じる。 結局、コマンドプロンプトからマウスで範囲選択してコピーして貼り付けるという荒業でクリアした。 普通の人は、何も考えずに、\を入力すれば良い。 最終的に SSD:　Cドライブ + ESP※ SSD:　Dドライブ(データストレージ用) SSD:　Eドライブ(データストレージ用) ※ESP(EFI System Partition) という構成に切り替えることができた。
コメントを投稿
続きを読む

Windows版gVimをアンインストールした日

Windows 版 gVim をアンインストールした話 以前に、 Windows11 on WSL2 + wezterm + Neovim = 最強開発環境 という痛々しい記事を書いたのだが、その続きの記事と言っても過言ではない。 この記事は Vim 駅伝 の 3 月 1 日の記事である。 前回はぺりーさんの netrw を使うために という記事だった。 次回は kuuote さんの Vim 側の組み込みプラグインを無効化するハック という記事である。 gVim との付き合い 思い返してみると、gVim との付き合いは大分長くなった。エディタとしては 自分の人生の中で最も長く付き合ってきたエディタ と言える。Vim のインターフェースとして gVim を何度も使ってきた。自分の手持ちのマシンは Windows なので、必然的に gVim を選択肢として選ぶ必要があった。 gVim の良さは何か。それは、Windows とのシームレスな関係であり、Windows OS の機能をそのまま使いたい場合に有用である。かつての自分にとってこの部分は非常に重要であった。具体的には、印刷機能と画面半透明化機能であり、これが無いとやってられないという認識であった。 しかし、時代が進み、自分の技術力の向上や考え方の変化、さらに Vim 周りのプラグインの更新が進むと gVim で運用していく事がだんだんと億劫になっていったというのが事実である。故に、 WSL2 上で動く Neovim の快適さに心が打ち震えた のである。 技術力の向上に伴う考え方の変化 かつての自分は 何でも gVim で処理したいな と考えていた。メールを見たり天気を見たり、Twitter を見たりするのに、gVim を活用していた。かつての Emacs 使いの guru のような立ち位置を目指していたというのがある。2000 年代初頭にインターネットに多少なりとも触れていた人ならば、「それ Pla」という古の単語を思い浮かべるかもしれない。この概念を持ち出すのはあまりにも古すぎるが、結局言いたいのは、 1 つの手法で全部をこなす という考え方だ。ネットを見るのにわざわざブラウザに切り替えるのはもったいないという今となっては情熱に似た何かを当時は多くの人が持っていた。 しかし、自分自身の技術力
コメントを投稿
続きを読む

javascriptは外部ファイルにした方がいいの？それとも、インラインの方が良いの？

事の発端 os0xさんのブログコメント で、javascriptの書き方について、面白いやり取りがありましたので、それについての私見を書きたいと思います。 結論から言いますと、プログラマ的な立場から言わせて頂くと、外部ファイル管理が望ましく、コーダ的な立場から言わせていただくとインラインが望ましいです。 なぜそのような結論に至ったのか、まずは経緯を御覧ください。 コメント欄でのやり取り os0xさんのブログコメント欄を引用しています
コメントを投稿
続きを読む