Using Firebase Realtime Database with complicated queries

Last week, I had a client who uses Firebase as a backend service. One of the clear issues he found himself in, is that he didn’t well design his database when he created his app the first time, which when the app grew up so fast led to a big amount of mixed data, neither he could well analyze it nor the user was able to have a good UX (‘cuz of the big amount of unnecessary data he has to download despite the fact he needs it or no ).

The Issue

Is there a direct Solution?

At first, it sounded like a good idea ( and it might be a very brilliant idea for your app to try) but the logic of the app I was working on, it will lead to a big amount of duplicated data and sometimes into a big waste of time (complicated logic + different nodes to listen to = a disaster in the UX ).

That’s why I tried to solve the issue from a different perspective. The data the app is using and working on when it starts the first time is so small. So starting from this point, I tried to store that data locally (with the magical Room ), and make as much of a complicated query (SQL Queries) as I want and implement any logic I want easily. At the same time, I kept the old logic, so when a user makes any action the app will be updating two endpoints, the one of the Firebase Database and the other one is the local one, but when he needs to query data, he will query only the local one. With this solution, we reduced the delay each user was waiting from 3 mins to 1–6 secs. (Yeah! that was like magic ! ).

Will this solution work always?

I didn’t put any code here, so if you have more technical questions don’t hesitate to leave a comment.


Full Stack Developer| Loading…

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store