Should you utilize Firebase in your next project?

Having worked with a wide range of databases, both relational and not, I find that the most tedious part of the development process is building out the data service. The data layer is the dumb layer that only does what the business logic dictates. So when building out this portion of any project, it’s just inserts, updates, deletes, selects, etc. No magic, just tedium.

If you’re working on a mobile application, you need to also build out and wire up an API layer so the app can communicate with the database. Don’t forget the authentication! Oh, and when there is a change to the business logic that dictates a change to the database you have to make sure to bubble that change all the way through the API. Again, not difficult just time consuming and tedious.

Don’t get me wrong, this is what people pay me to do, and quite frankly, I love it. But I have to admit, when I first used Google’s Firebase in an application, I was amazed at the simplicity and the rate at which I was able to get a working model up.

Not only is it a NoSQL data store, but the API to access it is all wrapped up into a nice little package; with authentication built-in! On top of that, it’s platform agnostic. I can use the same database for an iOS and/or Android app as well as a website. All without having to build out a data and API layer. And because it’s NoSQL, it can handle schema changes in realtime.

Is this solution for everyone and every project? No. Where would I use it in a real world application? Mobile applications, most definitely! In short, if you’re working on a mobile app and you’re trying to get it to market as quickly as possible and want it to scale if it becomes the next big thing, try Firebase, you’ll be pleasantly surprised; and so will your client.