このブログサイトは、Next.jsを使用して作成しているのですが、デプロイにはVercelではなくSSTを使用しています。SSTを使った感想としては、「セットアップが複雑でめちゃくちゃイライラするけど、カスタマイズ性は抜群」といったところです。では、詳しく説明していきたいと思います。

これはVercelの悪いところだと思うのですが、Vercelは料金プランが

しかありません。ですのでHobbyを超えて使いたいとなると、無料からいきなり月2000円まで跳ね上がってしまいます。

その点SSTであればAWSに直接デプロイしているだけですから、月額固定料金はなく、完全に従量課金制となります。

2. 他のAWSサービスとの連携が楽

SSTを使うと単一のコンフィグファイルでデプロイメントの設定が全て可能になります。しかもSSTの設定ファイルで連携を行うと、デプロイだけではなく自動で環境変数の設定等まで行ってくれるため、コード側で環境変数を手動で追加するといった作業も不要になります。またこのコンフィグファイルではサイトの設定だけではなく、例えば「S3のバケットを作成して、サイトに管理権限を付与する」といったことや「AWS Lambdaを利用して定期的に処理を実行する（cron機能）」といったことが簡単に行なえます。

Next.jsにはcron機能がデフォルトで備わっていないので（ISRはあるのに！）、この機能はかなり役に立ちそうです。当サイトでは、画像アップロード用にS3との連携のみ行っています。

3. コールドスタートを排除できる

AWS上でNext.jsのサイトをホストするとなると、SST以外にもAWS Amplifyを使う方法などがありますが、AWS Amplifyではどうしてもコールドダウンが発生し、ユーザーエクスペリエンスに悪影響を及ぼしてしまいます。これはAmplifyの問題というよりかは、AWS Amplifyを実行しているAWS Lambdaの問題で、大体15分間に一度も呼ばれていない関数はアンロードされてしまうため、次回の関数呼び出しで3秒ぐらいの待ち時間が発生してしまうのです。

ただこのコールドスタート問題も、SSTであれば定期的に関数呼び出しを行うことで関数をウォーム（warm）状態に保ってくれる設定があるため、いくら時間が経過してもコールドスタートが発生しません（いきなり大量にリクエストが来た場合は別です）。

SSTの悪いところは、ほとんどデプロイメントに集約されます。これはAWS自体の複雑さもかなり影響している部分もあって、どうしようもなさそうな雰囲気があるのが残念です。

1. デプロイの設定が面倒くさい

SSTでは、SSTの制作者が作ったseed.runというサービスを使ってデプロイントをすることを推奨しているのですが、正直現段階だとあまり出来が良いとは言えません。

といったところがあります。デバッグのしづらさが辛かったため、最初はseed.runを使っていたところGitHub Actionsに変えたのですが、残念ながら公式サイトにはGitHub Actionsを使った説明がないため、手探りで設定を探していく必要がありました。

SSTがAWS CloudFormationを使っているため、スタックに少しでも変更があるとCloudFormationの更新で果てしなく時間を食います。一回のデプロイで、大体10分はかかると思ったほうが良いです。ですから手動で毎回デプロイすることなんてしていたら、果てしなく時間を浪費することになります。CI/CD必須で、それでもやっぱりデプロイが長いのは辛い。

3. しょうもないところで引っかかるところが多い

Vercelでは動くプロジェクトでも、SSTだと以下のような不具合が発生しました。

3. 1. Next.jsのミドルウェアが動かない

Next.jsではmiddleware.jsをsrc以下に配置することで、全体のページに適用される事前処理を追加することが出来るのですが、なぜかSSTでは正常に動作しませんでした。Open-Nextのissueにも既に上がっており、どうやらNext.jsのバージョンを13.4.12に下げることで改善するようです。

3. 2. Node.Readableを直接express.Responseにpipeできない

Vercelを使っているサイトではReadableのpipeメソッドでexpressのResponseを渡すことで、S3から読み込んだファイルのストリームを直接レスポンスとして返却できていたのですが、なぜかSSTでは正常に動作しませんでした。仕方がないので、一度Readableを全て読み込んでBufferに書き込んだあと、更にそれをexpress.Responseのwriteメソッドを用いて書き込む必要がありました。

2023/12/1追記: SSTが利用しているOpen-Nextに更新があり、実験中のStreamingモードを有効にすると、AWS LambdaのResponse Streaming機能を利用してバイナリデータをBase64エンコーディングせずにそのまま返却するようになりました。このアップデートにより該当のバグは修正されました。

3. 3. Next/Imageにてsrcにドメイン名をつけないと動かない

SSTではCloudFrontを使っているせいか、srcを単に絶対パスで指定しても動作しません。ドメイン名をsrcに含める必要があります。

Vercelを使うとAWSとの連携が面倒で、かつお金がかかりますが、だからといってSSTを使用してもデプロイで果てしなく時間を食わされつらい目に合うことになります。ちゃんとしたウェブアプリを無料でデプロイするには、苦しみが必要だということですね。

ブログサイトをNext.js + SSTで作りました