Working from best practices. Emulators, security, and preview channels.
All Firebase backend services are housed by a Firebase Project. When you visit the console you select a project and the services related to that project show their associated data. You can own multiple projects for multiple apps.
To connect out to a Firebase Project we need create or use the configuration we call a Firebase App. A project can have multiple apps depending on the types of platforms it needs to support. If you’re just building a web app, then you only needs one app. If you’re going to build a cross platform app, then you’ll need an app for each platform.
Firebase comes with a JavaScript SDK that handles a lot for you. You don’t have to write any networking or caching code. The JavaScript uses the configuration of a Firebase App to know what backend service to connect to.
Firebase also comes with a CLI that can perform many actions. In this example we used it to deploy to Firebase Hosting. Stay tuned though, we’re about to use the Firebase CLI for one of the most useful bits of Firebase development, the Emulator Suite.
We saw a lot happen in that naive project. There was some good there, we created a realtime listener, did anonymous authentication, but there was no real good foundation. What was wrong?
Security is obviously the most glaring problem. With one DELETE request the entire database went away. In Firebase we use security rules and we’ll cover that IN DEPTH later today. I’ll also speak to them when designing the database and auth patterns.
I used initializeApp() everywhere. I had firebase imports littered in every file. As you begin to customize your Firebase app settings, you’ll run into erorr and weird bugs since nothing is consistent.
The entire site connects out to a production service. This is bad for billing, data integrity, and for general developer convenience. We have an entire Emulator Suite that lets your run all build services locally and in CI/CD environments. Not only does it run locally, but it also has a UI that is tailored for development tasks, such as quickly adding and deleting data.
Deploying to production each and every time is risky. Firebase Hosting has preview channels that let you deploy to short lived, generated URLs. You can even hook them up to work with pull requests on GitHub.
I didn’t take any time to think about my data model. Firestore is a NoSQL database that is not as query rich as other databases. There’s advantages and disadvantages to this. The primary advantages being, it’s realtime, scales horizontally, and it’s flexible with its data storage. When building for any database you want to lean into the advantages and that’s not happening here.
Let’s take this project and give it a proper Firebase foundation.