【DAY66】Firebaseアプリの再構築：無料の限界を越える改修へ

Firebaseアプリの再構築：無料の限界を越える改修へ

最近、自分が以前Firebaseで構築したWebアプリの改修に着手した。プロトタイプとしては十分に機能していたが、実運用を見据えた際に「無料枠では届かない限界」にいくつか直面していた。

なぜFirebaseを選んだのか

最初にFirebaseを使った理由は明確だった：

• サーバーレスでインフラ不要
• リアルタイムDBやAuthenticationのセットアップが簡単
• 個人開発なら無料枠で十分スタートできる
• デプロイが高速で、CI/CD連携もスムーズ

特にFirestoreやHosting、Cloud Functionsを使えば、少ない構成でそれっぽいWebアプリがすぐに立ち上がるのが魅力だった。

無料の限界とは何か？

改修にあたって、以下のような制約が問題になってきた：

• Firestoreの読み書き制限：アクセスが増えるとすぐ上限に達する
• Authenticationのカスタマイズ制限：ログインフローを細かく制御したいが難しい
• Cloud Functionsの実行時間：複雑な処理がタイムアウトしてしまう
• コールドスタートのラグ：Cloud Functionsの初期起動が遅くなるケースがある

開発初期には気にならなかったが、ユーザー数が少し増えたり、運用を意識するとボトルネックが見えてくる。

改修ポイント

以下のような方針で改修を進めている：

• 一部ロジックをJava + Spring Bootで再構築
  → 処理の重いバックエンド部分はFunctionsからJavaへ。柔軟性とパフォーマンスを確保。

• DB設計の見直し
  → Firestoreだけでなく、用途に応じてRDB（PostgreSQL）とのハイブリッド構成を検討。

• 認証と認可の強化
  → Firebase Authに加え、Spring Securityでトークン制御とロール管理を追加。

• ホスティング環境の移行検討
  → Firebase HostingからVPSやクラウドVMへの移行も視野に。

Firebaseを“卒業”すべきか？

Firebaseは非常に優れたプラットフォームで、特に以下の用途に向いている：

• MVP（最小限の実用的プロダクト）開発
• プロトタイピング
• 小規模なモバイルアプリ or SPAのバックエンド

ただし、以下のような場合には構成の見直しが必要になるかもしれない：

• 処理が重く、バックエンドでの細かい制御が必要
• ユーザーやデータ量がスケールしてきた
• サードパーティ連携や社内システムとの統合が必要

最後に

今回の改修を通して、「無料の範囲でできること」と「本番で求められること」のギャップをあらためて感じた。
Firebaseを使うこと自体は間違いではないが、技術選定は常に目的と規模に合わせて見直す必要がある。

今後もFirebaseベースの開発は続けつつ、必要に応じてJavaなど他の技術と組み合わせて、より実用的なWebシステムに育てていきたい。

---