What I learned from building this app, we've got a real-time database that is highly scalable and a lot more, in a lot of ways, more manageable than the real-time database was. The real-time database is great. I've done a lot of really cool stuff with that. But Cloud Firestore solves a lot; you had to be very nuanced with the real-time database.

With Cloud Firestore, you're able to structure stuff, in kind of the way you would think about your application, and build documents that start from a UI, backward. I think a lot of us, as front-end engineers, have gotten APIs. I like to joke at work that I can take any blueprint that the back-end team makes and build anything off of that.

I can take any designs that the UI/UX team makes and build anything based on that. But sometimes, when both of those documents cross my desk simultaneously, I can't do anything, right, and that's where it becomes difficult. And so I think being able to kind of think about, first of all, the number of apps that you could build now, that you probably wouldn't.

And this is the kind of thing we were talking about the other day, as well. But there are many times when I'm like, I want to build this app, and I sit down and am excited. And then I remember I have to implement authentication, and then all of the joy leaves my body, and I do anything else.

Now, I flip a switch. I've got some authentication. I think the number of apps that you can build and scale now, because this is on Google's infrastructure, right? Effectively, should you design and architect your system well, there's no reason that you couldn't scale this pretty well. You've got file storage, you've got a database, you've got authentication, we can run back-end functions, right?

For me, I think Firebase is one of the more exciting platforms to build just web services on. And I've had a lot of fun with it, and I plan on having a lot more fun with it in the future.

In the Real time database, you get whatever node of the tree you required and all of it's subnodes

This meant you had to be really careful about how you structured your data. In Firestore, queries are shallow

In Cloud Firestore, queries are shallow. You don't get all of the sub-collections by default

You still need to be mindful, but maybe less paranoid.

firestore.collection('posts').orderBy('createdAt','desc');

import firebase from 'firebase/app'

This gives you just the barebone minimum to get started

  import 'firebase/firestore'
  export const firestore=firebase.firestore();
  export default firebase;
  

We should never fetch any data in render method, as render is a pure function and calling APIs here may cause side effects. There is another lifecycle method that is a perfect match to fetch data: componentDidMount(). When this method runs, the component was already rendered once with the render() method, but it would render again when the fetched data would be stored in the local state of the component with setState(). Afterward, the local state could be used in the render() method to display it or to pass it down as props.

 componentDidMount=async()=>{
     const posts=await firestore.collection('posts').get();
 }

Query snapshot also holds onto a number of QueryDocumentSnapshots which inherit from Document Snpashot

docs: All of the documents in the snapshot id: The id of the given document exists: Is this even a thing in the database ref: A reference to the documents location in the database

data(): Gets all the fields of the object get(): Allows you to access a particular property

 const docRef= await firestore.collection('posts').add(post)
 const doc=await docRef.get()

 const newPost={
     id:doc.id,
     ...doc.data()
 }
 

await firestore.doc(`posts/${id}`).delete();

Instead of using get() which will get you the data each time, we will
use onSnapshot.

    firestore.collection('posts').onSnapshot(snapshot=>{
      const posts=snapshot.docs.map(doc=>({
          id:doc.id,
          ...doc.data()
      }))

      this.setState({posts});

    })

service cloud.firestore{
match /databases/{database}/documents {
//.....
}
}

# Security rules for cloud firestore
# This is the pattern for rules

service cloud.firestore {
  match /databases/{database}/documents {
    match /posts/{postId} {
      allow read: if <condition>;
      allow write: if <condition>;
    }
  }
}

resource.data will have the fields on the document as it is stored in Firebase

request.resource.data will have the incoming document

firebase.auth().createUserWithEmailAndPassword(email,password).catch(error=>{
console.error("Error")
})

firebase.auth().signInWithEmailAndPassword(email,password).catch(error=>{
console.error("Error");

})

this.unsubscribeFromAuth=auth.onAuthStateChanged(user=>{
    this.setState({user})
})

firebase.auth().signOut().the(function(){
//Sign out successfull
})
.catch(function(error){
//An Error occurred

});

Document Reference A DocumentReference refers to a document location in a Firestore database and can be used to write, read, or listen to the location. The document at the referenced location may or may not exist. A DocumentReference can also be used to create a CollectionReference to a subcollection.

get()

-Reads the document referred to by this DocumentReference.

onSnapshot()

-Attaches a listener for DocumentSnapshot events. You may either pass individual onNext and onError callbacks or pass a single observer object with next and error callbacks.

Cloud storage for firebase lets you upload and share user generated content such as images and video. Your data is stored in a Google Cloud Storage bucket, an exabyte scale object storage solution with high availability and global redudancy. Cloud Storage let's you securely upload these files directly from mobile devices and web browsers, handling spotty networks with ease.

Your files are stored in a Google Cloud Storage bucket. The files in this bucket are presented in a hierarchical structure, just like the file system on your local hard disk, or the data in the Firebase Realtime Database. By creating a reference to a file, your app gains access to it. These references can then be used to upload or download data, get or update metadata or delete the file. A reference can either point to a specific file or to a higher level node in the hierarchy.

If you've used the Firebase Realtime Database, these paths may seem very familiar to you—they should! However, your file data is stored in Google Cloud Storage, not in the Realtime Database.

In order to upload or download files, delete files, or get or update metadata, you must create a reference to the file you want to operate on. A reference can be thought of as a pointer to a file in the cloud. References are lightweight, so you can create as many as you need, and they are also reusable for multiple operations.

You can create a reference to a location lower in the tree, say 'images/space.jpg' by using the child() method.

var imagesRef=storageRef.child('images');

var storageRef = firebase.storage().ref();

var imagesRef = storageRef.child('images');

var fileName = 'space.jpg';
var spaceRef = imagesRef.child(fileName);

var path = spaceRef.fullPath

var name = spaceRef.name

var imagesRef = spaceRef.parent;

React has a higher order component called withRouter that will take all of this route information and pass it in as props to the given component

npm install -g firebase-tools firebase-admin
firebase login

firebase init


# Cloud Functions

npm install firebase-functions@latest firebase-admin@latest --save