理由1. SSR化させたくなった

ISSUEでは、issue投稿やトピック投稿できる機能があります。
そのページはSSR化させてOGPを表示できるようにしたり、クローラーからインデックスされやすくなったり、ページの仕組みとしての評価をあげたいと思っていました。

理由2. FirebaseHostingでSSR化させるのが大変だった

Next.jsはページ単位でSSR化させることができます。
早速issue詳細とトピックページをSSRしようと思いましたが、とても大変で挫折してしまいました。

なぜ大変だったかと言うと、ISSUEが採用しているホスティングサービスがFirebaseHostingだったからです。
FirebaseHostingにはnode環境はなくSSRはできないので、FirebaseFunctionsを使わなければなりません。

最初からFirebaseFunctionsを使いSSRさせていれば可能だったかもしれませんが、
これまでhostingだけでページ表示してきて、途中でFunctionsを使って表示させるのはとても大変です。

具体的には以下の点で困りました。

• FirebaseCloudFunctions のソースコード(functions) を別リポジトリで管理していたので、モノレポにしなければならなかった。(.next ディレクトリをfunctionsが読み込まないといけないため)
• Functions経由でページを表示させることはできるがデータ取得がうまく行かない。最終的にFunctionsで crash とだけログに表示されて、その詳細がわからなくて詰んだ。

FirebaseHostingとFirebaseCloudFunctionsは色々カスタマイズしたいときは不向き

ここで改めて、今のインフラ構成がサービスにあってるのかどうかを考えました。
FirebaseHostingは簡単にデプロイできて、すぐにサービスを始められます。

FirebaseCloudFunctionsも簡単にデプロイできて、運用コストもほぼかかりません。
初期はこれにとっても助かりましたが、運用していく中で課題も出てきます。

• FirebaseHosting

  • SSRできない
  • OGPを表示させたくなったら、Functionsと連携しなければならない

• FirebaseCloudFunctions

  • ログが見づらく詳細な情報がわからない
  • ローカルでのエミュレータによる動作確認が大変
  • 関数が多いと管理が大変

これらの問題を今後抱えていくとなると、なかなかスケールしづらい環境になる恐れがありました。
サーバレス環境のメリットデメリットは以下の記事が分かりやすかったです。
サーバーレスの理解とメリット・デメリット（2020年版）

テック企業を目指しているので、カスタマイズ性の高い技術者が好みそうな環境を整えたかった

ISSUEは、テック企業になることを目指しています。
テック企業は技術力があるエンジニアが集まる組織なので、プロダクトの質も高くなるからです。

そのためには、ISSUE自身が技術力を発信していくことになります。
そのときに、全く悪いとは思っていませんが、遊びのない技術を使ってることはプラスのイメージは持ってもらえないだろうと思いました。

ですので、CloudFunctionsで書いていた関数はGoで書き換えサーバも用意していく、FrontもAppEngineに移行する判断をしました。

まとめ

今回、FirebaseからAppEngineに移行する理由をまとめると、以下の2点かなと思います。

• Firebaseはセットアップが便利な反面、SSR対応のようなカスタマイズが大変
• Firebaseに頼りすぎると技術力のアピールがしづらい

Firebase自体を否定は全くしてないですが、
事業・プロダクトのニーズ・フェーズに合わせて柔軟な施策を打っていく必要がありそうです。