誤解しないでください。Firebaseがいいと思いますが、他の開発技術同様に、良い面と悪い面があります。ラピッドプロトタイピングには適していますが、コスト管理が手に負えなくなる可能性があります。 この記事で、Firebaseの利点、欠点、およびFirebaseの欠点を克服するためのプラットフォームへの移行に関する紹介について説明します。

　　　　Firebaseの11つの短所の解説： Firebaseから何を切り替えるべきか？

１．Firebaseとは

　　Firebaseとは何ですか？ Firebase は、Google のオールインワン クラウド サービスで、開発者向けにパッケージ化されて提供されます。プロビジョニングやクラウド構造について心配する必要はなく、フロントエンドに接続するだけで利用できる便利なバックエンドのフレームワークであります。

2.　Firebaseの長所の解説

2.1.　スピード

　Firebase は、何もない状態から瞬時に何かを作成したい場合に最適で、ラピッドプロトタイピングに適しています。完全に構成されたバックエンドが必要な場合、Firebase は頼りになるサービスです。

2.2.　Google エコシステム

　Google 製品であるため、他のサービスと完全に統合されています。Google ドライブ製品、特に Google スプレッドシートとの連携が可能です。

2.3.　便利なデータ変更

　迅速にデータの仕組みの理解とデータセットを新しいアプリケーションの移行ができます。　

2.4.　学習しやすい

　Firebase は高速で軽量で、バックエンド テクノロジの熟練度が低い場合や、時間やリソースが限られている場合に優れたソリューションを提供し、フロントエンドのユーザー エクスペリエンスに集中できるようサポートします。

3. Firebaseの11つの短所の解説: FirebaseからREST API を切り替えるかと検討する11つの理由

3.1. スパゲッティコード

 

Firebaseのスパゲッティコード

　サーバーレスだからといって、コードが不要というわけではありません。 Firebase を使用すると、すべてのサーバー ロジックが Web またはモバイル クライアントで直接実行されて、複雑に入り組んで、処理の流れが脈絡なく極めて分かりにくくソースコードのスパゲッティコードになる場合が多いです。さらに、クライアント上で実行することはビジネスにとって危険なものとなって、モバイル アプリも持っている場合はメンテナンスが悪夢になる可能性があります。

　更に考えてみましょう。データベース ロジックを変更すると、クライアント アプリが更新されます。 更新しなかったクライアントにはどのように対処しますか? 強制的に更新するかユーザーが古いクライアントを非アクティブ化する正しいことは何でしょうか?

3.2. Firebase とマイクロサービスの統合は良くない

　マイクロサービスを活用する際には、しばしばユーザー情報やIDなどの取得においてデータベースへのクエリが必要とされる事例が多く見受けられます。しかしながら、バックエンドからネットワークを介してFirebaseを利用することは非常に遅延が生じ、悪いユーザーエクスペリエンスをもたらす可能性があります。

　これらの操作をキャッシュする時、Firebaseはデータをメモリ内に保持し、未使用のリソースを解放しなくて、課題が発生することがあります。

3.3. 価格設定

　サーバーレスであるからと言って、必ずしもコストがかからないわけではありません。むしろ、自身の怠惰の代償をいずれは支払わなければならないことがあります。独自のサーバーコードを用いることで、保守性と生産性が向上し、コスト効率の高いコードベースを確立することができます。そこで、5ドルのDigitalOceanドロップレットで実行可能な内容に対して、月額100ドルを支払うことは、Firebaseを取り扱う際に熟慮すべき事項です。

3.4. Firebase はロード時にすべてのサブツリーをダウンロードする

　Firebase ではクエリ配列の長さを取得できない、順序付けされた配列をページネーションできないなどの理由でページネーションができません。A.Slack のようなアプリを構築していると仮定すると、アプリのロード時にすべてのチャネル データをダウンロードする必要があります。

3.5.不整合が発生する可能性

　Firebase はオフライン操作をサポートし、「git commit」のように機能しますが、問題は、クライアントがオフラインになってからオンラインになり、一部の入力データ (共有メモ帳など) で同時実行性がある場合、不整合が発生する可能性があることです。 Git のマージ競合とほぼ同じです。

3.6. データ移行の問題

　Firebase では、SQL データベース、ORM、ODM のように簡単にデータ移行に対処することはできません。

3.7. 関係処理が良くない

　NoSQL に比べて、Firebase との関係を扱うのは面倒です。その例を見てください。

NoSQLとFirebaseの関係処理可能

　ユーザーはまずteam_idsを監視して、それから自身の所属チームに組み入れる必要があり、一方でチーム側はuser_idsを監視してユーザーを登録することが求められます。この事例は単純明快ですが、全体をより多様な関係性で捉えると、スパゲッティロジックが引き起こされかねません。

3.8. キューにバグがある

　サーバー コードとマイクロサービスに対処するために、Firebase はサーバー間で操作を共有し、同時実行を防ぐためのキューを導入しました (例: 電子メールの 2 回の送信を避けるため)。この機能は Firebase チームによって十分に保守されておらず、同期の問題やロックなどを含むいくつかのバグがありました。

　さらに、キュー アイテムはすぐに挿入 (スタック) できますが、消費 (アンスタック) が非常に遅いため、キューはスケールのボトルネックでした。 さらに、クライアントに接続し、キューにレコードがあふれると、キューのタスク全体が大幅に遅延し、サービスが使用できなくなって、潜在的な DOS 攻撃となるかもしれません。

3.9. あなたは自分のデータを所有していない

　データが自己所有していないサーバーにてホスティングされているという事実の他に、ユーザーデータのエクスポートも不可能です。電子メールのエクスポートやユーザーアカウントの回復も同様に行うことはできません。

　さらに、数百メガバイトをホストしている場合、データのエクスポートは行えませんでした。

3.10. 複雑なクエリは不可能

　データベースにクエリを実行して、いくつかのプロパティを持つフィールドを見つけることは不可能です。例えば、アクティブ ユーザーを取得する操作を実行したり、一部のフィールドを含むドキュメントを更新するバッチ操作を実行したりすることはできません。

3.11. 製品の API を構築することは不可能

　現在、ほとんどのアプリが開発者 API を公開しています。これは Firebase では行えません。

　もちろん、クライアントから API リクエストを受信した際に、Firebase データベースにリモートでクエリを実行することはできます。しかし、データがリモートにあり、Firebase ライブラリでメモリリークが発生しているため、ホストの処理が非常に遅くなります。

4.　Firebase からの切り替える構造の紹介

Firebase から何を切り替える必要があるか

　REST API への移行を検討できます。データストレージのニーズの 90% をカバーする昔ながらの SQL データベースには、関係性とモデルがあり、完全かつシンプルで保守可能な API を作成するのに最適です。

　残りの 10% については、MongoDB を使用してメッセージや会話を大規模に保存することを検討できます。すべての CRUD 操作は REST HTTP レイヤーで実行され、一部の非同期応答は Websocket レイヤーで送信されます。更新は AMQP 経由で内部的に転送され、Socket.IO マイクロサービスと同期され、認証レイヤーによってサブスクライブされているリソースがフィルタリングされます。

　シンプルかつ効果的、そして持続可能。Socket.IO から別のエンジンに自由に切り替えたり、MongoDB から別のデータストアに移行したりできるようになりました。

5.　FAQ

問1.　Firebaseにはデメリットがあるのでしょうか？

　Firebaseがいいと思いますが、他の開発技術同様に、良い面と悪い面があります。

問2. Firebase の最大の弱点は何ですか?

　Firebaseの潜在的なコストは膨大になり得て、企業にとって危険な側面を有する可能性が考えられます。

問3.　Firebaseを切り替えるべきでしょうか?

　悪い特徴はあっても、Firebase はまだいいサポートを提供します。 なぜなら、Firebase の悪いポイントは管理可能であり、その影響に直接影響を与え、軽減することができるからです。 Firebase には SQL (インターフェースとして機能する別のバックエンドが必要) よりも優れた機能があり、このサービスには開発フローを迅速化する独自の事前統合セットが付属しています。

　Firebaseは悪くありません。 完璧なサービスというわけではありませんが、宣伝文句どおりのサービスであり、モバイルファーストのアプローチでアプリケーションを迅速に作成できるプラットフォームを提供します。

6.　まとめ

　　Firebaseの主な利点は、フルスタック開発者の立場から複雑なレイヤーが取り除かれる点にあります。しかし、Firebaseの従量課金モデルにおいては遅延データ構造が生じる可能性があり、または、コストが急速に膨れ上がる可能性があります。

あなたにお薦め：
モバイルアプリ開発にFirebase を使用する10つのメリット

　Firebaseの潜在的なコストは膨大で危険性を孕んでいるように見えるかもしれませんが、データ構造に常に注意を払うことの重要性を強調し、警鐘を鳴らす役割も果たし、ビジネスにとて、悪いことであると言えません。

　Firebaseは単一のインターフェースとデータ取得の標準化された方法論を通じて作業が円滑化されるため、人気のあるフレームワークであります。最近、Firebaseと他のフロントエンドフレームワークを流合する必要があって、そのうち、Firebase x Flutterの2つのテクノロジープラットフォームを組み合わせが現在一番一般的です。ご興味があれば、参考リンクを以下にご提供いたします。

　

https://miichisoft.com/flutter-firebase-great-integration-for-mobile-app