ラボメンバーの「いちろ～」です。
検証を体験してもらうための公開環境をどうしようか悩まれたことはありませんか？
・できるだけコストを掛けたくない
・構成はシンプルなものにしたい
・利用する技術は最小限にしたい
・すぐに公開して体験してもらいたい
小さく、コストを掛けず、すぐに使ってもらえる環境を欲することがありますよね。
従来はラボで経験してきた Amplify を使って構築していましたが、いくつか不満点がありました。
- フルスタック前提なので使わない機能も含まれる
- フレームワークのバージョンなどに指定がある
- Figma to Code（デザイン to コード）の環境がやや使いづらく、更新も活発ではない
そこで、もっと適した構成がないか探してたどり着いたのが
Bun × Next.js × Lambda
です。
構成について
Lambda というと、これまでは API として利用するイメージが強かったのですが、コンテナベースでのリリースも可能で、Next.js のイメージをそのままアップすることができます。
また、Lambda の Function URL を利用することで、従来は API Gateway や Application Load Balancer（ALB）を使って公開していたエンドポイントを、Lambda 単体でも作れるようになりました。
構成を見てみましょう。
これでフロントエンドの画面UIもバックエンドのAPIも実装できて動きます。
AWS 上での設定も比較的難しくなく、短時間で構築できます。
どうでしょうか。シンプルではないでしょうか。
構成的なメリット
１．CI/CD パイプラインの高速化
エンジニアが最も「待ち時間」を感じるのは、パッケージインストールとビルドです。
Bun を使うと、この部分が明らかに速くなります。依存関係の解決は体感レベルで高速で、npm や yarn を使っていたときと比べて「待たされている感覚」がほとんどありません。
結果として、
「コードを書いてから環境に反映されるまで」のサイクルが明らかに短くなりました。
PoC のように“回転数”が重要な環境では、この差は想像以上に大きいと感じています。
２．ローカルと同じ構成で動かせる安心感
AWS Lambda Web Adapter（LWA）を使うことで、Lambda 専用のコードを書かずに済みます。
標準的な Web 開発として next start で動くアプリケーションを、そのままコンテナとして Lambda に載せることができます。
handler(event, context) といった Lambda 特有の書き方を意識する必要がないのは大きな利点です。
また、コンテナベースなので、将来的に Cloud Run や Fargate へ移行する場合も、大きな改修なしで対応可能です。
３．コールドスタートとコスト面
フレームワークごとLambdaに載せてしまう時の弱点はコールドスタートです。
しかし、軽量なランタイムである Bun を組み合わせることで、その弱点を克服しています。
コンテナ起動からアプリの立ち上がりまでが軽く、少なくとも PoC 用途では「コールドスタートが気になる」という印象はほとんどありません。
これが、この組み合わせの大きな利点だと思います。
また、実行時間が短くなれば、そのままコストにも影響します。
ミリ秒課金の Lambda では、軽さはそのまま効率につながります。
最後に
Bun は進化のスピードが速く、Node.js との互換性で問題が出ることもあるようですが、私が構築した範囲では特に問題には当たりませんでした。
実際に使ってみた感想としては、
「早い、安い、使いやすい」
という印象です。
構築方法については調べると情報が出てくるため今回は割愛しますが、PoC 環境としては一度試してみる価値はあると思います。
おためしあれ！(ノ・ω・)ノ
