Firebase：サーバー側のロジックとリアルタイムデータベースの制限クラウドコードを解析するために同等の

Question

サーバー側のカスタム操作：

解析がcloud codeを書くための可能性があります。私の理解から、Firebaseはコンソール上でこれを行うためのツールを提供していません。

これを行う唯一の方法は、Firebase APIを使用してWebサービスを実装し、ノードの変更を監視し、自分のサーバーにクラウドコードを実装することです。

• A - これは間違いありませんか？

サーバー側のルール：Firebaseの

legacy documentation /書き込みだけでなく、検証を読み取ることができるユーザーを決めるに限定されているように見えるのルールを説明しています。

{ 
"rules": { 
    "foo": { 
     // /foo/ is readable by the world 
     ".read": true, 
     // /foo/ is writable by the world 
     ".write": true, 
     // data written to /foo/ must be a string less than 100 characters 
     ".validate": "newData.isString() && newData.val().length < 100" 
    } 
} } 

オンパッセージでは、ルールの複雑さが大きくなります。プログラマは、カスタム操作を実行するための関数を作成することができます。

私はFirebaseにこの複雑さを持っていない理由は、おそらく、ノードベースのデータベースは、テーブルベースのものよりも複雑であり、それということであることを想像：Firebaseをそのままに設計された理由を理解

開発者がweb-apiとカスタムサーバーアプリケーションを使用してこれを完全に制御できる場合は、より良いでしょう。

• B - これは正しいですか？

リアルタイムデータベースの制限： Firebaseのようなリアルタイムのデータベースを使用して主な制限は、私には思える

そのデータは2ウェイの冗長性のイベントが含まれている場合は、いくつかのリアルタイムデータをフェッチしたら1つのノードでトリガされたノードは、冗長な情報を含むノードに伝播されません。

など。ユーザーノードにキーid（ユーザーノードの同じレベルにある別のノードのID）があり、キーリストが変更されているかどうかを検出するために、ユーザーがテーブルビューにあるキーの一覧を表示すると、 （ユーザーノードの変更だけでなく）キーノードの変更を聴くことができます。

- C：これは間違いありませんか？

Answer 1

質問は、使用例がないので曖昧ですが、コメントに基づいて、ここに行きます。

A）はい、多分。 はい、サーバー側ロジック（コードワイズ）はありません。 多分、あなたがしようとしていることに依存します。

B）Firebaseルールは非常に柔軟です。ルールは、誰がデータにアクセスできるか、読み取り/書き込みアクセス、どのような種類のデータ、データの種類、データの場所などを制限する可能性があります。これは、データを検証、検証、保存する別の方法です。

FYI：Parse wasは、文書ベースのNoSQLデータベース（テーブルベースではありません）であるMongoDBによってサポートされています。バックエンドでは、ParseデータはFirebaseと同様の方法で保存されていました。 （実際はBSONです）。フロントエンドの実装は、JSON構造を包んでいるオブジェクトで、Firebaseよりもテーブルのような感じで、PFオブジェクト間の関係を直接的に持つようになりました。

C）いいえ。ノードの変更を確認できます。あなたの例では、キーノードを/ userノードとは別のノードとして設定し、ユーザーに/ keysノードを観察させるべきでしょう。

これを少し拡張すると、必ずしもデータが冗長である必要はありませんが、それは可能です。関心のある特定のデータの変更を観察する必要があります。

各ユーザーの/ usersノードと/ favorite_foodノードがあるとします。あなたのUIがユーザーのリストを表示していて、そのうちの1人がお気に入りの食べ物を変える場合、あなたは本当に気にしません - ユーザーのリストに興味があります。つまり、/ favorite_foodノードではなく/ usersノードを観察します。