Firebase Fundamentals

Dev Config Best Practices

Firebase Fundamentals

Check out a free preview of the full Firebase Fundamentals course

The "Dev Config Best Practices" Lesson is part of the full, Firebase Fundamentals course featured in this preview video. Here's what you'd learn in this lesson:

David discusses what went against best practices in the previous Firebase demo and briefly demonstrates implementing best practices for security, code structure, production services, deployment, and data models. A student's question regarding if Firebase sets up a WebSocket when talking to the database is also covered in this segment.


Transcript from the "Dev Config Best Practices" Lesson

>> So, what did we learn through this? We learned that with the Firebase project, that's a big just container for all of my Firebase services. You create a Firebase project and then you create a Firebase app that allows you to connect to these services. Then we you the Firebase SDK to write to this services or read data from this services.

And we use the Firebase CLI to do deployment, but a lot went wrong. So first of, security, like I said, advising a DELETE request to that database, everything gone, and that's not good. Also the code structure. In every single route in every file I was writing, import Firebase app, get this, get that, and that's really verbose, and we don't need that.

And also, I'm developing against production services, that's probably not a good idea. We've seen all of the memes and all the T-shirt,s about how it's bad to do things in production. And so these are cloud enabled services, I should be able to do that without having to worry about network connectivity or messing with data across the synchronized environment.

And also the deployment here, I'm deploying out this. This was my site, this markdown-me, I'm deploying out to production every single time to see my changes. And that's not great, I would like to have a staging space to be able to do those deployments as well. Another thing too, I kind of just very much hand waved over collections and documents and all that.

And I was just kind of like, hey, I wanna write data really quick. I'm not really thinking about my data structure. And FireStore is a NoSQL database. And there's a lot of great things and a lot of great structuring you can do with NoSQL, but you have to know what you're doing.

And I didn't realize it, I was just writing data. So what I'd like to do, is I'd like to go and make this better. So to do that, I'm gonna go into the best practices setup, cd.., cd.. And then, which one is it CD to best practices setup, CD start, and let's open up this one.

>> Is there a place where the final code is published?
>> Yes, yeah, in every folder there is a start and there's a final. And the final is already pre-baked, so if anyone just wants to go look at them right now that's already there, yeah. So within here we have the same project as we had before, I have a different project in this case, but it's all fine.

What I have my Firebase, everything is all set up. What I want to do now is I want to set this up so I'm not talking to production services, and I wanna rewrite my code structure a little better. So I'm gonna create a file called firebase.js. Now there are more advanced ways of structuring your Firebase code, but I'm gonna show something that I think is sort of like a tried and true, battle tested way of writing service code that kind of survives across weird development things like hot module replacement, which can be really weird with things that are stateful.

And so I'm gonna go through, and I'm gonna write what I think is a really good way to handle your Firebase setup. So I'm gonna import from Firebase app, and we're gonna call InitializeApp. And then I'm gonna import from the config, just like before, and we'll get the config.

And then, now I'm gonna create a function called, Initialize(). And I'll create a Firebase app inside of here, say initializeApp and call config.firebase. But I'm also gonna want other services. So I'll import from firebase/firestore. And also want auth. So within here all of these two services. So I'll say get oath, just auth, sorry, is getAuth and then getFirestore as well.

So I could just export this function, and then from within here I could just return all of these services as an object for other files to use. But I'm gonna wanna do some more advanced things. So if I'm running locally, I wanna run against the Firebase emulator suite.

So Firebase comes with a whole set of emulators, so I don't actually have to talk over the cloud, I get a sandbox development environment. So I can import data into it, I can export data out of it, I can just start from scratch with every single run, it makes it really easy to develop.

And the emulator suite also comes with its own local UI that is tailored for development tasks, that is different from the console UI, yes.
>> When talking to the database, does firebase setup a web socket versus in web socket?
>> That's a great question.
>> Or how does that data syncing [INAUDIBLE]?

>> It depends on which database you use. So that Firebase doesn't just have one database, it has two databases and so the original database is called the real time database. And that is actually back in the days what people used to refer to as That's my Firebase would refer to the database.

Now Firebase is more than just the real time database. That database we're not covering today because it has shares a lot of similar philosophies and FireStore just has a lot more features. So I want it to Focusing on that, but the real time database sets up over a WebSocket connection and that's how that one works with FireStore.

it doesn't use a WebSocket, it uses HTTP to do like a long live HTTP connection. And there's a whole real time server that knows how to send the delta of changes that happen. So even though you ask for a stream of all updates if a user only updates one document out of a collection of 100 of them, when that new on snapshot fires, it might give you that whole data object back, but it's only going to sync the changes that occurred over the network.

So you're not doing a whole other set of reads because it's aware of what data is locally available and only what data had changed. So it really helps cut down on bandwidth consumption

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now