さまざまなアプリケーション(iOS、Android、Web)でFirebase DBロジックを書き直すことを避けるため、以前はこのロジックを保持するためにサービス/中間層を使用していました。この方法では、アプリケーションはDBと直接対話しません。 しかし、FirebaseとGoogle Cloudの機能を備えた新しいアーキテクチャでは、すべてのDB呼び出しをクラウド機能経由でルーティングすることが賢明でしょうか、これはユースケースに基づいてのみ選択的に行う必要がありますか?Google Cloud機能でFirebase DBロジックの重複を回避できますか?
これまで見たほとんどすべての例で、このアプリはFirebase DBと直接的にやりとりされています。クラウド機能は特定のイベントだけを聞き取り、選択的に使用することを意図しています。彼らは中間層であることを意図していません。 このアプローチでは、すべてのアプリケーションでDBロジックを複製する必要が生じます。このコードの複製を避けることはできますか?
ありがとうフランク! Firebase機能を使用すると、リアルタイムのDB機能が失われ、通常のWeb API呼び出しを使用するようになります。あなたが指摘したように、オフライン機能が必要ない機能や、ビジネスロジックが複雑すぎる機能の場合にのみ、機能を使用します。 Firebase Dbに直接アクセスして、リアルタイム機能を活用することができます。 –
"Firebase機能を使用すると、リアルタイムのDB機能が失われ、通常のWeb API呼び出しを使用することになります。必ずしも。結果をデータベースに書き戻すデータベース・トリガー・クラウド機能を使用している場合でも、クライアント側アプリはデータベース・クライアントであり、リアルタイム更新を取得することができます。 –
はい、データベースに書き戻されるデータベースによってトリガされるクラウド機能は、リアルタイム機能を活用するのに役立ちます。この機能は、次のような例を参照してください。https://firebase.google.com/docs/functions/use-cases#perform_database_sanitization_and_maintenance Could関数のドキュメントで説明したように、これはデータの保守/追加処理が必要な場合に便利です。しかし、大部分のDB操作(CRUD)では、コードの書き換えを避けるためにキューに書き込むことで関数を使用すべきではないと思います。クライアント側のFirebase SDKを直接操作して、オフラインの処理機能を活用する方が良いでしょう。これは、異なるクライアントすべてのコードを別々に書き直すことを意味します。 –