Production環境でNextのSSGやってるけど、辛いところと留意点を公開していく

本記事について

Sympathyという採用関係のSaaSを新規開発しており、そこでNext.jsを使用しています。そこでの知見（辛いところ、留意点）をメモがわりに残しておこうと思い書きました。

前提

Sympathyというアプリケーションについて

Sympathyというアプリケーションはクライアント（ユーザ企業）側の管理ページ群と外部に公開されるメディア側のページ群があり、後者のページ群をStatic Genrationによりビルドのタイミングでデータを事前取得しページ生成しております。つまり全ページ静的サイトとして作っているのではなく、Hybridでやってますよという話です。

言及しているバージョンについて

Next.jsの9.3以降

ビルドのタイミングについて

• リリース時
• GCPのCloud BuildとCloud Schedulerを利用し、定期的にビルドをスケジューリングしている。

経緯

• 今後メディア側へ注力していくにあたり、スピードは正義だと思った
• Next.js 9.3以降のアップデートにより比較的ローコストで実現できそうだった

辛いところ or 留意点

ビルド時間が長くなる

当然ですが、静的に生成しているページ数（Sympathyでいうとクライアント数）によりビルド時間がどんどん伸びていくのでビルド時間が伸びる。ある時間に取得したコンテンツが公開されるまで十数分かかったりする。

サーバレスで動かすのが辛い

上記のビルド時間については定期的なビルドをやめ9.5に出たIncremental Static Regenerationで一般的に解決すると思われるが、SympathyではGoogle App Engineを利用しているので毎回同じインスタンスでリクエストを捌くというわけでもなく、かつRe-generationによるビルド結果が永続化されるわけでもないので、これも辛い。
それ前提でインフラアーキテクチャ組めよっていう話かもしれないが...

まとめ

辛いところを書いたが概ね満足しているし、今後も使っていきたいと思っているが、活用するには考えること色々あるよねっていうのを共有しておきたかったです。
プロダクションでこういう風に活用しているよっていう話があれば是非お聞きしたいです。
Vercelは？みたいな話もありますが、会社で使うにあたり他メンバーも関わるとなると中々利用に踏み切れないでいる。