Firebase Played Us!

What is Firebase?

To put it very simply, Firebase is an external database service. They define themselves as:

“A set of back-end cloud computing services and application development platforms provided by Google” for more information check here: https://firebase.google.com/

Besides database services they also offer authentication and integration services for various applications too. Applications and programming languages supported are: Flutter, Dart, C++, Android, IOS, JavaScript, Unity engines and Java.

Why does all this matter? Because we used Firebase in the development of our application. Not only that but we used it’s most popular service: it’s database service.

Database preferences?

We may ask, why even use Firebase ? Firebase is easy. When doing any type of development project which will require you to save user data in some forms, then you will require a database. This might be to store the user data for later analysis, data modification, data protection, data restoration etc. This applies to companies, individuals and organisations, and even to more groups too.

Now that we know why we use databases we must ask the next question. Which database types are better for us?

There are three main options:

1. Centralised databases

2. Decentralised databases

3. Database as a Service (DBaaS)

Let us explore these differences. While we do that, try and guess which database type Firebase falls into ;) .

Centralised databases: This is when the database that is being used for the application is stored in a place where the persons using it have direct physical access to. They can also edit, improve, update and reconstruct the database in anyway they desire. Essentially, you have complete ownership and edit-ability of the database in all ways physical, internal and in terms of digital infrastructure.

Decentralised databases: This is the complete opposite of centralised databases. They are web3 based databases. They are databases where the storage devices are spread across different computing devices. Only specific organisations can customise and improve on the databases internal functionality. Their use cases are limited. They are mostly made for web3 apps, tokens and for hosting other web3 products.

For more info on web3 databases which explores them more fully check here: https://www.makeuseof.com/what-is-web3-storage-how-does-it-work/

DBaaS: This database type is often referred to as “serverless”. This is because with this database type, which is similar to centralised databases, you do not keep hold of the database locally near you. The database is hosted through a 3rd part company and they allow you to customise certain digital infrastructure of your database but nothing more. The main selling point of this database is cost effectiveness. Instead of hemorrhaging funds to create your own centralised database you instead opt to out source the efforts. Someone does the dirty construction work and you can rent from them to use their database services. You get different functionality for different pay-tier levels.

I opted to use DBaaS. Firebase is a DBaaS. I opted for it because of the cost-effective nature of this database model.

Firebase rejects my users:

I am making an app. One of the functions the app has is the ability to register, sign-in and sign-out users. As you can see in the picture above I made a test username to sign-up and a test password. Once I pressed the “sign-up” button the app sent the information to my relevant database. The database being hosted in Firebase. Upon attempting the sign-up I remained on the same app page and nothing changed. After checking the users in my Firebase no new user was registered at that time. This means my user was not registered.

We need our app to recognise new users. At this stage a developer will look at their code and may look at the Application Processing Interface (API) for Firebase and how they called it in their code. They will also look at the variables which define users to make sure it’s defined properly and functionality is well. They may also check to see if anything that interferes or interacts with the connection to the database needs to be updated, such as the libraries used or the Firebase API link itself. One may do all these steps or more to find the solution to the database ignoring our calls. There is one problem.

None of this applied to me. Why is this so?

The reason I did not have to do any of these standard debugging practices is because a little while before this new attempt, I was able to register new users to the database. Within a week this suddenly stopped. Without changing any of my code the process which worked before was not working anymore. This confused me greatly and I repeatedly replaced my API call link and put it in different areas. I organised my reference calls for my libraries being used to and my different file calls. I even went online to enquire if Firebase’s database service was down. This was not the case. I was then about to start standard debugging practices…..Then I finally found the solution! it was in my emails all along.

Solution Found:

Yes, my email had the solution all this time! Upon checking my email after days of stagnation on this issue, I found a notification email from Firebase. Firebase notified me that my database access had been cut. This was because during the Firebase database setup I had setup my database access to be cut at a certain date for security purposes. I had forgotten about this rule I added for myself. I had forgotten about the date I specified. As a result when I was cut off I did not notice until checking my email. Below we can see that I set the database to cut me off on the 12th of March 2023.

To fix this issue I just needed to update the rules to extend the time frame for my “cut-off “date. As seen here:

To solve the issue I put the next deadline for June 29th. In this way, I will not have any interruptions again until that deadline.

One may ask “Why not set it to a few years from now or more months from now so you arent bothered with it?” good question. I will not do that because I want a few quarterly reminders throughout the year to remind me of this dependency. I do not want to set it for a long term deadline and then forget about it again and be stuck in the same situation a year later. To have it repeatedly conscious in my brain would mean I am constantly thinking of all factors that can affect app development which will be helpful as I continue the development process. One might call this a learning preference.

Below we can now see my functioning sign-up functionality:

We can see the Firebase Authentication procedure even returns a user id token as the user's special identifier, that is how we know it is registered.

Development is fun, but we always have to be conscious of the little things. Most times when there are problems with the application it is most likely due to our own code error. However, sometimes problems might not even come from our code. It really could just be something as simple as a needed update or like in this case, simple database rules review.