Firebase Database in a (tough to crack) nutshell
By now I’m sure you are aware of Google's Firebase and you’ve most likely even used it in some projects.
I’ve used it several times. However, to begin with, I didn’t understand how Firebase Database worked. Firebase Database, according to the docs, lets you;
“Store and sync data with our NoSQL cloud database. Data is synced across all clients in realtime, and remains available when your app goes offline.”
I’m sure we can all see the benefit of having an SDK which handles all the syncing and storing malarkey, but how do I move my SQL data structure to NoSQL?
Against the grain
Before we begin, I should issue this public health warning - You’ll probably hate it to begin with.
You are allowed to duplicate your data, by which I mean you can de-normalise. Normalising is the process of organizing data to minimise redundancy.
In practice, this involves dividing a database into tables and then defining relationships between them.
For example, having one table for ObjectA and then other tables referencing an entry in the ObjectA table by its id.
De-normalising can be a difficult thing to get your head around but the reason you do this is to reduce your querying complexity.
As a simple example, consider a structure where you have a Message table and a User table, and each message has a reference to the user that sent it.
If you wish to display the name of the sending user, you have to first get the message. Then pull out the id of the sending user, and then fetch the user.
You may have done this with joins but that’s what was happening. Thus in this simple example, you had to do 2 queries to get that information.
In Firebase Database you would store the whole/partial (as much as needed) User object under the message object. Therefore only needing 1 query to retrieve the same data.
Although this is a simplistic case you can see that if you scale this up you can make massive savings on queries, making them simpler and quicker.
There is a cost to de-normalising and that is - data consistency.
Using the same example as above, occasionally a user might change their profile - their name for instance.
This change then needs to be reflected on not only the User node but also the Message node. This process is aided by the Firebase SDK, which provides methods for making this process transactional (i.e. all pass or all fail). For more information check out their docs.
You could also utilise the eventually consistent approach. Using the Cloud Functions feature in Firebase, you can kick start a server side task based on a particular trigger.
For example, whenever the User node is updated, you could apply the same changes to the Message node.
Which is best?
I’m sure that you could argue until you're blue in the face over whether and an SQL or a NoSQL database is more suitable. But it is worth considering the door this can open into Firebase.
The Firebase feature set is quite extensive and, although they can all be used separately, when used in conjunction with each other, offer something rather magical.
To use the Firebase Database it is likely that you will want to use some security rules. For example, only authenticated users can write to the database.
This is all well and good, but security rules in Firebase should be thought of as just Rules. They provide an interesting way of validating your data and filtering the content that a particular user can see.
For example, you can write a rule such that only authenticated users with a given uid can read messages which have field 'sent_to' matching that uid.
Not only does this protect your data but also can reduce your querying complexity again.
If you’re interested in using Firebase then check out their docs:
If you want a more in depth look at the content I have covered here check out these videos on YouTube. I highly recommend them.