Why we used firebase?
Listen to this on Odiocast.com
Today I am going to tell you why we used firebase when building Odiocast.com
Prior to building Odiocast.com, Ravi and me were crunching numbers and running fancy queries to derive insights at PureMetrics.io our earlier venture. We were running on top of Google Cloud Platform using mostly managed services. We were simply blown away with the power of Google BigQuery, Cloud Dataflow, Google App Engine and used it as much as possible.
I believe thats one of the major reasons why we felt comfortable with GCP when compared to AWS. Since we had limited man power, we always prefered managed services.
While I’ll leave the discussion of managed versus unmanaged cloud services for another day, I will stick to “WHY Firebase”.
Firebase has been around for sometime now, before being acquired by Google, it was solely a real time database which had fine grained authentication built into the product. I had a chance to use it way back when it was in BETA for a personal project of mine. It was good then and it still holds up the reputation.
Firebase is really good for prototyping an application. You do not need to write server side APIs or marshalling and unmarshalling or consumption of the same. You do not need to put constraints on your DB design or even worry about authentication rules. Firebase Database rules are pretty good for most of your needs when you are starting out. Backing up and restoring the database is also very simple.
What makes firebase truly effective is the Cloud Functions which allows you to write your custom code to execute business logic based on firebase triggers, like sending a welcome message when a user signs up or updating the DB when a file is uploaded to cloud storage.
If you Google a bit you’ll find a bunch of sample apps which showcase chat apps or real time collaboration built on top of firebase. The fan out feature does come in handy when building such apps.
You might ask me if I do recommend anyone to use Firebase for production apps. To be honest I am not very sure how long we will stick to using firebase. Firebase auth strictly ties the service up to Google Play Services and that in itself has a lot of limitations if case you are building for the world and not just devices which have Google Play Services.
If you plan to build using only firebase tools and services, the first challenge you will face is with Firebase Analytics. Firebase Analytics does not support web. Apps are just a channel of communication. Your user might be on any or all the channels web/app/on call with your customer care or even in your store in case you have one. It is important to measure all the touch points for the service that you provide.
From where I stand the only reason Google did this was of GA premium. With Google Analytics you would need to pay a premium to get the data exported to BigQuery in order to run your own queries. It does come with a few more perks, but free export in itself is huge.
While Remote Configs is undoubtedly the best feature firebase has to offer, it’s too small to hold someone back. While we gradually transition to Neo4J and MySQL, we will continue to use Firebase for some time to come.
