Essential tips for Firebase users
Ride easy in the slipstream of my mistakes
Add users to your Firebase Database
There is currently no way to bulk export Firebase Auth user data from the Firebase Console. The support team at Firebase have suggested two ways in which you can bulk export your data, but I didn’t find either suggestion particularly convenient.
Update: as Akshay Raje pointed out, it is now possible to export user accounts in their entirety, in either JSON or CSV format.
The first suggested method is to send an email to Firebase support, requesting a payload of your user data. Obviously, this isn’t an ideal solution for cases when you need to regularly export your user data (like updating a mailing list before sending out a new campaign).
The second method suggested by the Firebase support team is to follow the workaround outlined in this document. In a nutshell, it involves creating a service account key in the Google Developer API Console, converting the key using the OpenSSL tool on the command line, then using an ‘Identity Toolkit’ sample repo on GitHub to retrieve your data.
Not exactly ideal.
Fortunately, I stumbled upon a more feasible alternative, which is to save users to your Firebase Database when they sign up. You can easily save email addresses or auth UIDs from federated providers (like Google, Facebook, and Twitter) to Firebase Database, thereby creating your own copy of your user data — free to export whenever you like.
Here’s how you can save users to your Firebase Database:
Please note, if you require password hashes, your best bet is still to email Firebase directly for now.
Know the difference between .on and .once
This was the cause of multiple bugs for me.
The .on() and .once() methods are both used to retrieve data from your Firebase Database.
The .on() method listens for changes in the data and runs its given callback each time the data changes (on change).
The .once() method on the other hand, only runs the callback the first time the data is retrieved.
This occasionally tripped me up when I forgot the exact syntax for retrieving data from Firebase Database, so I would copy and rename another function which was retrieving data. Due to the similar naming of the two methods, it was easy to overlook that I was accidentally using .on() instead of .once() (or vice versa).
Using the wrong method introduces a bug which is annoyingly subtle. The first time you run the code in a browser, it retrieves data from Firebase Database, so you assume that it’s working. However, the unexpected behaviour only begins later, when a callback you expected to run once is running multiple times (or vice versa).
In my case, I had a situation where users informed me they were receiving multiple copies of the same email in their inbox. I discovered that this was because the email logic was in a callback passed to a .on() method when it should have been a .once() method.
Keep Firebase logic server-side
Storing the majority of Firebase-related logic server-side introduces a number of benefits:
Separation of concerns
If you ever decide to migrate away from using Firebase Database, you’ll only need to update the server-side app, and you won’t have to refactor your client at all. This is because your client simply consumes the API that the backend exposes, so it doesn’t know anything about Firebase Database or where the data comes from.
Also, there will be less duplication of logic if you decide to create multiple clients. This proved incredibly helpful for me when I decided to create a Chrome extension to compliment my web app.
Reduced vendor lock-in
Firebase Database provides “server-side” data validation through a Rules API. This is helpful for validating data when you only have a client-side app, but it does introduce an element of vendor lock-in. The Rules API is completely proprietary and specific to Firebase, meaning you’ll have to rewrite it entirely if you ever decide to use another database program. Therefore, writing your own server-side validation logic makes you less dependent on this proprietary format.
If you are apprehensive about writing server-side code, you’ll be surprised at how easy it is to create a “production ready” Node.js/Express app. Express has a Getting Started guide which is a great place to start.
Using Firebase Auth as a promise
Remember that the onAuthStateChange() method is just an observer, so if you ever need to ‘fetch’ user data and only act on it once (like a promise), you can simply unsubscribe from the observer once it retrieves the data you require.
Like any of the words from this story? Check out Vocabify, a vocabulary builder which helps you learn the words you come across.
