Playing With Fire(base)
While working on my own pet project here at the Flatiron School, there have been multiple roadblocks I have encountered. Many of these were code related, being that I am only four weeks into my time here. But, I have also run into some data and memory issues with my app. Displaying a bar/restaurant’s menu seems easy in theory, but there is far too much data to hard code into the app itself. This left me to seek out a solution where I could pull this data down from a server or cloud when it is called upon in my app. After talking to my instructors and doing plenty of research on my end, I kept coming across one name. Firebase.
Firebase is described as a server-less, cloud based data solution. In lieu of paying for the space for a server, developers can pay for Firebase based on the amount of usage their apps get, the more they pay. There are multiple plans FIrebase offers, with varying amount of storage and data transfer caps. (more users, the more you pay).
Firebase also features a bunch of neat tools in their dashboard. They offer a simple analytics dashboard to monitor the usage of your app, tools for user login, authentication, and security, and of course your standard database.
Firebase ultimately has its strengths and weaknesses. Its biggest draw is the speed at which it handles data requests, operating in real time and making the user experience seamless. They also provide other development kits (GeoFire and WatchKit) that give developers more flexibility and tools for their application should they choose to use them. Firebase does have it’s drawbacks, however. Being that it is meant to be a cloud-based data storage solution, the database itself is a bit raw and is tough to read navigate when you first dive into it. I myself have recently started using it and still find myself wondering what I am looking at. This weakness of Firebase opens the door for certain competitors with stringer database features for its users.
Parse was the other name that I kept seeing consistently when researching these types of databases. At it’s core, it is a server-less data solution for developers like Firebase is, but offers a slightly different product. While Firebase seems to be the leader in speed and reactiveness with its database, Parse allows developers to do more with its database. Many users of Parse shower the site with compliments of having a more polished and mature database. Many people seem to agree that this is wher Parse has a leg up on Firebase. Parse can also be utilized across multiple systems and languages, offering at least six products for each Mobile, Web, and IoT/Embedded products (i.e Texas Instruments).
Being that they have a more refined database, Parse seems to be able to handle a higher amount of users on a given application with a database with can be built at scale. Like Firebase, there are also drawback to Parse. Speed is one of them, but this is not to say that Parse is slow. For developers that value speed and fluidity in their application, and minimizing load times, Parse may not be for them. I also found multiple reports of Parse having issues with crashing on users and trouble making database calls, in tandem with poor customer support.
Firebase, as well as Parse, are both interesting solutions to using a database without having to pay a large amount of money for server space. Each offer great products and are geared towards the varying needs of developers. Both are powerful tools in and of themselves. They can even be leveraged together to maximize the capabilities of an applications as well as the cloud-based products themselves.