Skip to content

Firebase Analysis

Jump to bottom
Jin Zou edited this page Sep 17, 2018 · 20 revisions

Comparison

Data model

Both Realtime Database and Cloud Firestore are NoSQL Databases.

Realtime Database

  • Stores data as one large JSON tree.
  • Simple data is very easy to store.
  • Cheaper for apps that make lots of frequent updates
  • Complex, hierarchical data is harder to organize at scale.

Cloud Firestore

  • Stores data in documents (key-value stores) which are grouped and organized in collections (containing more docs).
  • Shallow queries: can request docs without also retrieving all data underneath.
  • Querying scales to size of result set, not data set; queries are fast no matter how large data gets.
  • Complex, hierarchical data is easier to organize at scale, using subcollections within documents.
  • Requires less denormalization and data flattening.

Authentication

  • Either use FirebaseUI or Firebase SDK to authenticate users. FirebaseUI is built on top of Firebase SDK.

FirebaseUI

  • JS library to streamline user auth with email/password sign-in as well as support for providers such as Google/Twitter/Facebook
  • Contains React wrapper for easy integration
  • Handles cases such as account recovery and account linking
  • Mobile-friendly implementation

Firebase SDK

  • More customizable but requires significantly more configuration
  • Supports email, provider, and phone number based sign-in options
It looks like you're using the development build of the Firebase JS SDK.
When deploying Firebase apps to production, it is advisable to only import
the individual SDK components you intend to use.

For the module builds, these are available in the following manner
(replace <PACKAGE> with the name of a component - i.e. auth, database, etc):

CommonJS Modules:
const firebase = require('firebase/app');
require('firebase/<PACKAGE>');

ES Modules:
import firebase from 'firebase/app';
import 'firebase/<PACKAGE>';

Security

Firestore

  • Every request to/from Firestore is evaluated against established security rules before reading/writing any data.

  • If rules deny access to any of the requested document paths, the entire request is invalid.

  • Cloud Firestore also provides a rules simulator to test the ruleset. The simulator can be accessed from the Rules tab in the Cloud Firestore section of the Firebase console.

  • Rules can be deployed by using either the Firebase Console's Rules tab or the Firebase CLI

Rule Structuring

  • All Cloud Firestore Security Rules consist of match statements, which identify documents in your database, and allow expressions, which control access to those documents:
service cloud.firestore {
  match /databases/{database}/documents {
    match /<some_path>/ {
      allow read, write: if <some_condition>;
    }
  }
}

  • All match statements should point to documents, not collections. A match statement can point to a specific document, as in match /cities/SF or use wildcards to point to any document in the specified path, as in match /cities/{city}.

  • You can only access documents that your security rules specifically allow you to access. In the previous cities example, the rules shown only allow access only to documents in the cities collection; they also deny access to documents in all other collections.

    • As a result of denying access to subcollections, explicit rules must be given in order to access them through the use of a nested match statement.

  • Refer to the use of recursive wildcards in the documentation linked in the title of this block.

Conditions

Queries and Rules

Links

Clone this wiki locally