koudenpaのブログ

趣味のブログです。株式会社はてなでWebアプリケーションエンジニアをやっています。職業柄IT関連の記事が多いと思います。

AWS Amplify での Next.js SSR 所感

従量課金かつお手軽にフロントエンドをSSRするのがそれなりの関心事であることもあり、AWS AmplifyのAmplify Hostingの表層に触れたのでメモしておく。

動機

先日までは serverless-next.js を試していたのだけれど、近々のnextのv13対応はなさそうなので他のデプロイ構成を試してみようと思った。

デプロイ先はAWSかつ従量課金な構成を前提条件としているので、そんなに選択肢は多くない。はず。

従量課金で構成するには、コンピューティングをLambda系とする必要があるけれど、Next.jsのSSRをLambdaで動作するようにパッケージするのは結構大変っぽいのでスクラッチは当初から捨てていた。

で、この辺かなぁ? と2つ当たりを付けた。

どのみちAWSに激しくロックインされるなら、ファーストパーティが提供しているサービスを使っておくか~と思ってAmplifyにした。

SSTは構成がちょっと面倒くさそうだったという「お手軽に」考慮も多少はあった。

AWSコンソールでポチポチ構成できるのは大層良い

案内に従ってAWSコンソールをポチポチしたら既存のNext.jsアプリケーションのSSRが従量課金で構成された。

正直多少は躓くところや面倒なところがあると思っていたので拍子抜けしてしまった。

この「お手軽に」構成できるのはとても良い。

AWSが弱いところはことごとく弱いのはイマイチ

が、どうにも「痒いところには手が届かない」。

状態の通知

Amplify 単体ではメールでの通知をサポートしている。

これをSlackのチャンネルへのメール通知すれば最低限の用は足りるかと思ったけれど、ファーストビューに情報量が皆無でイマイチだった。

Slackへの通知例。情報量が皆無でびっくりする。省略されたもう少し先にどういう通知なのか書かれている。

メールタイトルや本文の冒頭に具体的な状態を記載して欲しい。特にタイトルはひどいもので情報量がほぼゼロだ。

EventBridgeやSNS、Lambda等を組み合わせれば好きなイベントだけを好きな形式で通知できそうだったがそんな面倒くさいことはしたくない「お手軽に」がテーマなのだ。

せめてメール通知同様の手間でChatbotと接続して欲しい。

2023/04/30 追記

環境によってはステータスまで見えて便利だった。

Slackアプリでの見え方

!!! CustomerError: Framework Web not supported

!!! CustomerError: Framework Web not supported ←なんやねんこれ。

ちょいちょい発生して苛ついていた。

ググると解決法はヒットする。

zenn.dev

Amplify Hostingはデプロイ対象のアプリケーションのフレームワークを自動認識するのだが、その自動認識が間違っているとAWSコンソール上からは手も足も出なくなる様子で、APIを呼び出して正しいフレームワークに更新しないといけないようだ。

Amplify Hostingはブランチ毎に環境を生やすことができるのだけれど、同一アプリ隣の環境でNext.js SSRが動いていてもWeb!と認識してくれる。

素朴に意味わからん。

アプリケーションに対してはこのアプリは「Web compute」であると設定するだけで、フレームワークは設定できない様子なので、ブランチ毎に環境が生えるごとに判定ミスの恐れがあるということだろうか。

本当か? 指定できそうなものだけれど、今のところ頻繁に環境を生やすつもりはないので忘れることにした。

PR毎にレビュー環境を生やしたりするようなら(Amplify Hosting自体はそれに対応している)判定ミスするようでは話にならないので何とかする必要があるだろう。

無料枠は1年

ややしょっぱい。

aws.amazon.com

感想

普通にNext.jsのSSRができるのはいいのではないか。

Vercelと比べてどうなのかとか、新バージョンへの対応がどうなのか、とか考え始めるとどう考えてもVercelなのだろうけれど、ほとんど何も考えることなくブラウザでポチポチするだけでNext.jsのSSRホスティングできたのは結構よい体験だった。

しかも組み込み機能でBasic認証を構成できる。

AWSでお手軽にNext.jsをSSRするならなかなか良い選択肢なのではないかと思う。