Firebase for Startups-The Goods vs the Bad

What is Firebase?

Around a decade back, when Firebase was not Firebase it was known by the name of a startup called Envolve. The startup was all about providing the developers API’s which enabled the integration of an online chat setup into their website. The tech geeks started using Envolve for much more than its basic functionality, that was to pass app data which was a lot more than just chat messages, they used the product to sync app data such as a state of a game across its users in real-time.

Seeing the hype, James Tamplin and Andrew Lee, the founders of Envolve separated the two uses of the app i.e. the chat system and the real-time architecture. In April 2012, Firebase was made as a separate identity which just provided backed as a Service with a real-time functionality.

Google acquired Firebase in 2014, this helped the product to rapidly evolve into a versatile behemoth of the web and web platform that it is today. This acquisition helped the developers to make a connect with the key cloud tools such as a storage or database through a bunch of software development kits (SDKs). With this, it has added on refined functionality like monitoring in order to fix the performance issues and get access to analytics in order to see the user engagement, among all the other things.

While Google boasts 1.6 million apps monthly running purely on Firebase, the company is rigorously working on making every developer using the solution a smoother one.

The Why & Why Not’s For using Firebase

Just like anything else Firebase comes with its fair share of advantages and disadvantages, let’s discuss them in detail, let’s start with the great features.

Real-time Database

Isn’t this awesome, yes it is. With some scrutinization and some data binding spells developers can connect their views with the data and  wizardry change when the information/data changes. This functionality is a cloud-hosted NoSQL database which lets the developers sync and store between the usages in real-time. Firebase database uses a single API to provide your application with the present data value as well as any updates that happen within the data. This real-time syncing helps the users to access the data anywhere and from any device, be it be mobile or the web, it allows the users to collaborate with each other all in the real-time.

The cherry on the cake is that real-time database ships easily with the web and mobile SDKs, thereby allowing the developers to make the apps without any specific servers. This way even when the app users go offline, this functionality lets you use the device to serve and store all the changes. And when the devices are back online, the information is synchronized automatically.

Static hosting on steroids

The solution gives its developers a free CDN and SSL hosting- all this running on the Google Cloud Platform. This leads to zero problem(s) when it comes to serving the files to numerous users across the globe.

So, if you are looking for a zero-configuration hosting for the next single-page app or a static website invests in Firebase, it will work great even if you don’t make use of any other Google service.

Auto-magical Scaling

Firebase is efficient enough to do scaling with the help of its Real-time Database feature, but things may go haywire once your app starts getting popular among the users or in case your database becomes huge.

Cloud Firestore is based on Google Cloud infrastructure, this lets it to scale out a lot more with all ease and to a much bigger capacity as compared to Real-time Database.

Some More Super-Powers

Firebase has a big bag full of more services and SDK’s which are not only very easy to integrate but also make the whole development process a cake-walk and smooth, some of them are-

• Free tier

• Database backups

• File storage

• CLI (Command line interface) for deploying and other functions

• OAuth authentication

Some Firebase features which may be good, but not that good

The Console

The Firebase console lets the developers do a lot of things, but it has its own flaws. The database manager is basically an elevated JSON editor; it does some great work but it is not a completely seasoned solution which the crowd was hoping it to be. This will be a great toy to play with for folks from Mongotron, WorkBench, Postico or PHPMyAdmin.

The console also lacks analytics or detailed logs, this is so unlike data-obsessed-Google’s product feature. So, unless you implement a functionality in the app, there is no way through which you can know the number of times a file was downloaded from the storage.

Defining security rules

The Google solution uses a JSON file with a JavaScript code in a string(s) when it comes to defining rules over storage and database.

This may sound little problematic but since you can use other exterior solutions like Bolt this process becomes little easy. But working with Bolt is easy till a few rules after that it becomes unattainable.

To keep your sanity intact while development you can use services like Graph Cool, Dream Factory, etc. for an efficient working in this case

Can We Develop Locally? NO

If you have poor connectivity every now and then or if you travel and work Firebase is not for you as it can’t work with a local installation. You cannot just open Node or Docker  and start working on your API.

Firebase’s few completely No-No pointers…

Limited JavaScript SDK

Firebase has a few features which can only be implemented in iOS and Android SDKs.
The strongest one of the lot is the lack of offline commitment while working with JavaScript. All the React Native, the web or hybrid app solution will keep on working even if the gadget goes offline for some moments. But just when you close the tab or the app, the data will be unavailable. It’s the developers call if they want to carry on a cache with all persistency. This is really important concern, especially in case on the mobile.

The JavaScript SDK has no way to cache the data(unsure about Android or iOS). With Firebase if you upload the data /products and then everytime you want to make a change you have to reload it except for times when developers manually keep connection running in the background.

It isn’t very hard to implement this, but can’t the Google peeps give us a magical way out to do this?

Querying Data? No Way!!

The Firebase system just allows you do just a little filtering and some pagination and nothing more. This is very unusual that Google is providing the world a data service but without any filtering or searching possibilities.

If developers want to execute any search functionality, they’ll have to download all the existing data and further use a server(like I wrote above) or effectively carry out the process using a third-party service like Elastic.

Data modelling? Please improve it Firebase

One big JSON file, that’s what a Firebase Database exactly is. Developers have no way out in case they want to mention one to many or many to many more connections. This is let them just duplicate the data over and over again every now and then.

Doesn’t sound that bad, after all its all about putting the name of the app user in the chat message. Right?

The real problem arises when you have to edit a given name since developers have to modify the name from all the places its been used and not just in /users.

And telling the app users that they can’t change their names doesn’t sound good, therefore:

• The client code for writing and editing data to Firebase will be like a messy salad.

• Documenting the complete information about where all the data has been duplicated will be pretty difficult.

Several NoSQL databases like RethinkDB or MongoDB have answers to this problem, It should not be grueling for Google to find one for Firebase also.

Concluding note

With all this being said, Firebase is a powerful tool especially for small organisations and individuals who are not very experienced when it comes to developing back-end of an app.  Firebase has its fair share of disadvantages also, but they can be overcome with a little tweak or help from external sources. What’s your take on Firebase? Let us know in the comments below.