Useful Tips For Firebase Projects
Firebase is a really incredible platform, but how to fully maximize its capacities? Here are some key tips to make your Firebase based apps great!
Fan-out and multi-path updates
It’s pretty evident that the first thing we need to do before we start developing any app, is to think about how to structure the data generated by it. When we use Firebase, data replication is one of the key things to be considered in this process. Imagine a super simple application that consists of users who read and publish posts. The relational approach that first comes to our mind is the following:
It looks very nice, but what happens when our application needs to list all the published posts? In order to get the author’s name, we’re going to need an extra request for each post. If our list has, for instance, 100 posts, 100 extra requests will be needed to get the author’s name for each post. It’s possible to reduce this number if we use some kind of cache,
however the necessary amount of queries needed to show a simple list is not performant. We need to denormalize our structure.
How would it look if we decide to replicate the author’s name and include it on each of their posts? Let’s see:
Now we no longer need any extra query to get the author’s name of the post. No matter how many posts we have, we need just one query. Fine. But you’re probably wondering “what if a user decides to go to their profile and change their name?” In that case, we should update that information on each place where we replicated it, I mean, on each post created by the user. For this situation, the Firebase SDK provides us the multi-path updates:
Great! The most interesting thing is, that in addition to updating multiple routes with just one request, the whole operation is atomic. This means that the entire update may fail or succeed, and we don’t have to deal with any intermediate state.
NOTE: this is a simplified example. What is missing here is a way of getting the posts ID’s that the user has created. A good idea would be to store them in /users/:userId/posts. Then, iterating that list, we could get all the ID’s and complete the fanoutObject with all the relevant routes.
Firebase Testing Server
We already have the data structure finished, users here, posts over there, great! Time to start coding. One of the most important things on any software project is to have the highest test coverage as possible. This should not be the exception, but with Firebase, how we can do it? In Lateral View we have created our own base project to test security rules or functions interacting with the Firebase real time database. The Firebase Testing Server is a local Firebase server (thanks to urish/firebase-server!) on which we can define the initial data, security rules, validations and perform read and write operations using the Firebase SDK.
Everything runs locally, which obviously is much faster than running the tests against the online database. Also, if we’ve lost Internet connection or maybe we decide to travel to the desert (?), we can still code… great!
Firebase Queue
Now imagine that users can add comments on posts. When this happens, the author of the post should receive a push notification on their phone and an email with the details of the comment. In addition, there must be some kind of automated system that filters unwished or offensive comments.
We might do this directly from the application. First we should have to deal with the API’s of the services that send emails and push notifications. We should also make use of some external process or service responsible for sanitizing the message content, or do it right there on the phone.
But if we consider that our potential users will not always be connected through a wifi network, it’s clear that this approach is not the more appropriate. Internet from the mobile network is not always a fairy-tale: we have to assume that in many cases our users will have low or even no connection. In addition, nothing prevents a user to close the application in the middle of the whole process. Makeing a big number of requests every time users leave a simple comment, undoubtedly leads to a continuous generation of errors and incomplete states.
The best option is to do this in a background process and out of the phone. Here is when Firebase Queue comes to our rescue.
As you can see in the image, the concept is quite simple. We just have to add a new task on /queue/tasks and then our worker will do the rest. Firebase Queue allows us to launch multiple workers, configure retries, divide a task into multiple jobs, and more. For more details, I recommend reading the project guide.
Do you know other good tips your own? Share them with the world in the comment section below!
