Cloud Run上でのexpressとhonoのパフォーマンス比較

最近、JavaScript界隈の盛り上がりがすごいですね。
zigで作られたJavaScriptのランタイムであるbunは、その便利さ・パフォーマンスの良さから驚くような勢いで広まっています。その一方で新たな軽量WEBフレームワークhonoも非常に注目されています。
honoもbun同様にパフォーマンスが良く、エッジサーバーでの実行を想定しているようで非常に軽量です。Cloudflare Workersを筆頭に、さまざまなランタイム上での動作をサポートしておりbunも対象です。

github.com

話は少し変わりますが、自分はJavaScript(Node.js)でマイクロサービスを作る際はexpressを脳死で選択してきました。
実行環境はプロジェクトの技術選定の制約がありCloud Runになることが多いです。しかし、現在となってはbunにhonoといったexpressよりも軽量でパフォーマンスが良いとされる素晴らしいものが登場しています。
とはいえ、いきなり本番環境に採用するのは難しいため、今回は1つのエビデンスとなるようにCloud Run上で動作するexpressとhonoのパフォーマンスを比較してみたいと思います。合わせてランタイムをbunにした場合のパフォーマンスも計測します。

毎朝、味噌汁を飲んでます(一汁一菜でよいという提案...を読んで)

少し前から、ずっと調子が良かった肌が荒れてしまいました。
元々、敏感肌で弱いアトピー持ちで季節の変わり目や花粉が飛ぶ季節になると、肌が荒れることがあったのですが、今年は今まで以上に肌の調子が悪くなりました。さまざまな要因があるため「これが原因だ...」という断定は難しいのですが、原因の一つに食事があるのではないかと感じていました。

意外にも自炊はしっかりとしていて、カップラーメンや冷凍食品を口にする機会はほとんどありません。
ただ、朝ごはんだけは時間の都合でトースト１枚にジャムやマーガリンを塗って食べるというスタイルなのですが、どうもトーストやマーガリンに含まれる「トランス脂肪酸」が肌の調子を悪化させているのかも...という仮説に至りました。

※自分が調べた限りでは「トランス脂肪酸」が必ずしも健康に悪影響を及ぼすものとは断定できませんでした。
※あくまで自身の仮説であり、トランス脂肪酸を否定するものではありません。

ということで、朝ごはんをパン中心のスタイルから健康的なスタイルに変えようと思ったのでした。

サブクエリとLEFT JOINのパフォーマンス比較(集計編)

業務で集計処理を書く予定があるのですが、サブクエリとLEFT JOINのどちらを使って集計した方が良いのかを判断できませんでした。もちろん、データ量やデータ特性、トレードオフなどを踏まえて判断する必要がありますが、今後、同じような場面に遭遇した際にデファクトスタンダートとなるのはどちらかなのかをハッキリとさせておきたいです。
世の中には「推測するな。計測せよ」という言葉があるので、実際にサブクエリとLEFT JOINでそれぞれ集計処理を計測してみました。 結果的に今回のパターンではLEFT JOINの方がパフォーマンスが良かったです。

では、詳しく紹介していきます。

テーブル定義

以下のようなテーブルがあったとします。
ユーザーはポストを任意の数だけ投稿できるように、中間テーブルuser_postsを定義しています。

今更ながらHTTPのRFC(Status Code Definitions)を読んでみる

みなさんはRFC読んでますか...🤔
自分は普段、ガッツリと読む機会はないのですが、新しいプロトコルを触るような場合に読んだことがある程度です。
過去にWebSocketを使ってSlackライクなチャットアプリを作ったことがあるのですが、その際にWebSocketのRFCを読んだことを覚えています。
しかし、WEB開発において最も使用しているであろうHTTPプロトコルのRFCを読んだことはありませんでした。
直近でいくらかAPIを設計する予定があって「良い機会だな...」と思うので、HTTPのRFCを読んでみようと思います。
といっても、文量が多いため、まずはステータスに関する項目(Status Code Definitions)のみに絞りました。どのステータスがどのようなケースを想定して用意されているものなのか興味があります。

www.rfc-editor.org

内容を理解できるかは自信がありませんが、RFCにはどのようなことが書かれていたのかを紹介していきます。

sequelizeで全テーブルに対してTRUNCATEを実行する

業務でsequelizeというNode.js製のORMマッパーを触る機会がありました。
単体テストを実行する度に、データベース(MySQL)のテーブルをクリア(全削除)するために制約を無視してTRUNCATEを全テーブルに対して実行したいのですがsequelizeでは対応するメソッドは提供されていませんでした。

// 外部キー制約のあるデータが存在しているとエラーになる
await sequelize.truncate({ cascade: true, restartIdentity: true });

// テーブルに対応するモデル1つずつに対して実行する必要がある
await User.destroy({ truncate: true });

Model Querying - Basics | Sequelize

テーブルをドロップするという手もありますが、その後にテーブルを再作成・マイグレーションを実行する必要があるため非常にコストが高くなってしまいます。何とかならんものか...と悩んだ結果、生SQLを実行することにしました。
簡単に実行できるように関数化したので、同じ問題で困っている人がいれば使ってみてください。