Firebase and 5 common mistake mistakes

I recently read a lot of online comments about Firebase. Most of them are from developers who hated Firebase.

It is also not difficult to understand because they are all the deadlock problems they encounter when using Firebase. However, sometimes they stem from their misunderstanding about Firebase and its function.

Mistake 1: Firebase is just about client-side

Just recently, Firebase is still công nghệ client-side . However, it still allows storage and querying. However, most things are done in the client. For developers, is this really hard to swallow because there is no web application that doesn’t need a back-end?

The Firebase team then listened to feedback from the user community. In March 2017, the team introduced Cloud Functions for Firebase. With cloud functions, you can save code snippets to Google Cloud. These code will run when a Firebase events or HTTP requests appear. For example, if you want to perform data processing while saving data in the database, you can now do it with Firebase .

If you want to know more then I recommend you to read the following article Cloud Function for Firebase docs .

Mistake 2: Firebase is the cause of the lengthy code

There is a saying that “Bad people always blame”, with my experience using Firebase, it does not make you write long “code”. Because Firebase is mostly on the client side, your backend logic will also be targeted to the client. Therefore, if you are not careful, it is easy to produce bad and confusing code. ; In the early stages of project development I decided to create a connector to connect to Firebase. It has all the code for CRUD operations as well as interact with Firebase. In addition, I also gathered a list of classes to handle the data of the object based on the structure of Firebase database. Thanks to this, everything is always clear and makes the code easier to maintain and fix.

Mistake 3: Bad data modeling / too much duplication

As the Firebase members themselves said, the Firebase database is just a giant JSON tree . Data is stored as key-value pairs and can be valued as you like. There are many ways to store them, so be very careful if you don’t want to get in trouble.

Let’s say you want to create a simple project management application. You have users and tasks. Tasks can be assigned to Users. You will want to store all of the task’s information in a database of tasks node:

Now if you want to show the names of all Cathryn tasks. To do that, you can query the database to return tasks “assignedStaff” with the value “Cathryn”.

The problem is that it will return all the tasks assigned to Cathryn, not just the task name. In other words, there is too much redundant data.

To remedy the above situation, Firebase encourages you to denormalize data. Denormalization is a term that refers to storing copies of data in the database, in order to improve processing and reading.

Now if we name the tasks assigned to Cathryn, we will simply read from a location in the database:

Compared to the query above, it will process a lot faster.

Denormalization sounds like hacking. But it is required to design a Firebase database for web applications with large scale and complexity. Requires you to be very knowledgeable about the data you want to store and how to use it.

Before jumping in to create a Firebase database, take the time to learn about denormalization , how to structure your data , and how to maintain them .

Mistake 4: Firebase can lead to inconsistent data status

If you design the Firebase database properly, chances are the data from across your database has been denormalized. And if your data is stored in many different locations then you will probably ask yourself, “How to keep the data consistent?”.

Normally, when sending data to Firebase, you specify a database path as well as the type of data you want to store. Returning to the example, to update a task name (before using denormalization), I will do the following:

Now with denormalization, I can update a task’s name with two operations:

It will, however, be prone to inconsistent data. What if one operation fails while the other succeeds? That’s why we need an automatic write operation to allow the creation of database paths at the same time. Therefore, Firebase has provided multipath updates to address this issue. You can see how to use them here . Now updating a task name will only need to do the following:

Mistake 5: The ability to querying is very limited

Firebase is really very limited when it comes to queries. You can sort data by keys or values ​​and filter data.

Based on the example above, we can create a query to retrieve tasks starting from, before or after 20170601. However, we will not be able to filter by multiple values ​​and keys. In other words, the query to revoke assigned tasks to Cathryn and start after 20170601 is impossible.

Of course, this is always the subject of complaints of many developers. However, everything has its cause, Firebase is a real-time database and is designed with the goal of fast processing. So to get a complicated query will require you to design your database properly.

For example, if you want to make a query to retrieve assigned tasks to Cathryn and start from 20170201. I can add a “staff_startDate” property to my tasks:

Thus, when needed we will only have to query as follows:

I encourage you to take a look at Common SQL Queries converted for the Firebase Database and Firebase Database Querying 101 . Once you understand the structure and the query data, you will be able to do more complex queries.

Thank you for reading. Source: freecodecamp