In Need of Parse Alternatives? Let’s Look at Firebase!

Until recently, Parse has been the go-to solution for mobile developers who needed to persist application data to the cloud without having to set up and run a custom API backend. All of this changed in January 2016, when Parse announced that they would be ending the service in 2017. Even before Parse announced its termination, Google’s Firebase has gained popularity as an alternative. Despite the fact that Firebase does not offer a direct conversion mechanism from Parse, we decided to evaluate it for Bookdash, an open source project that we contribute to.

What is Firebase?

In a nutshell: Firebase is a cloud-based NoSQL data storage service with close to real time updates. It offers features such as automatic updates, syncing, and caching mechanisms for mobile clients. In addition, it also has mechanisms for user authentication and authorization to data. All of the data can be viewed with the Firebase console in a JSON tree structure and all authentication and authorization logic is written in JSON.

What Are Its Strengths?

This list is not exhaustive, but an application with the following characteristics would be ideal for Firebase:

• Simple data structures
• Simple authorization and authentication rules
• The need to quickly update data between clients that share data
• The need to scale

Given that most mobile applications fall into one or more of these categories, Firebase makes it easy to get started and be productive.

What About Complex Data Structures?

Granted, things do get a bit more interesting when your application has complex data structures. Since Firebase is a NoSQL data store that uses data, there is nothing to stop you from storing nested data in a format. Consider the following example:

{"Books":
    [{'author' : {
        'name': 'Matz'
        'publishers' : [{
              'company_name' : 'Pearson'
              'company_addresses' : [{
                   'address1' : '1 ruby way'
                    }]
              }],
         'author website' : 'www.ruby.com'
         }}
     'title' : 'Ruby Rocks'
    }]
}

In this example, we use a nested data structure to store data about a book. Let’s say that we have a very simple application that gives users a list of books along with the respective authors. Theoretically, you could simply store the data in a nested JSON structure. At first glance, it might seem like the obvious thing to do if you’re receiving all of the data from another source in a nested feed. There are, however, two problems with this. First, what happens if some common biographical information about a author needs to be changed (for example, the author’s website)? With the current data structure, we’ll need to update every book that we have in the data store. This might be a reasonable trade off if we have 10 books, but what if we have 1,000 or 1,000,000 books? If we have a mobile application that writes directly to Firebase, this would clearly be data intensive and highly impractical. Secondly, if we attempt to retrieve a list of book titles and authors only, a query against the data store will also return a lot of unnecessary nested data (such as the publisher, publication date, etc.) Again, this can cause the application to have excessive data usage and slow down query times. One way to fix this would be to normalize the data.

{'Books':
   [{'author' : 1,
        'title' : 'Ruby Rocks'
   }],
'authors' :{
    1 : {
         'name': 'Matz'
         'publishers' : 1,
         'author website' : 'www.ruby.com'
        }}
    },
'publishers' : {
    1 : {
        'company_name' : 'Pearson'
        'company_addresses' : 1
        },
'company_addresses' : { 
     1 : {
          'address1' : '1 ruby way'
         }
    }
}

This resolves one problem, but now we need to query against two top level JSON objects in order to get a book title and author. Two queries will not be a large performance burden, but what if our application needs a list of the book author, title, publisher name, and publisher address? We’re up to 4 queries. Now, what if we have a normalized data structure that spans 7 or 10 objects?

Denormalization

To fix the multiple query problem, we may need to have redundant data in multiple objects. For example, we may create one top level object in Firebase that has a nested data structure and another that has the normalized structure. If Firebase is only hooked up to one web application that manages all of this, it may add a bit of complexity, but it would remain manageable. One major advantage of using Firebase is that you don’t have to stand up your own server. It has native clients for Android and iOS that do a lot of the heavy lifting around getting, putting and offline data access for your Firebase DataStore.

Many Clients

If you have only one application that can write data, the data structure may be a reasonable trade off. But, what if you have an iOS and Android Client that also has the ability to edit the address for Pearson? More importantly, what if there are a few thousand book titles in your repository that were published by Pearson? This would, again, create two problems. First, a mobile client might have to update a lot of records. Second, it increases the chance for out of sync data, since two codebases need to stay in sync with the updated data structure.

Using a Hybrid Approach

One possible solution is to set up your own server to manage writes between the mobile applications and Firebase store. You’d have to deal with maintaining another application stack, scaling it for traffic, and manually deal with data writes from the application. You could still have your app directly read from Firebase (which has a lot of advantages), but you would also add complexity to the system.
.

Should I Use Firebase?

Firebase is a good choice for many applications. If you have a simple data structure, it will handle a lot of the data sync and caching for you, and create a very robust back end that can deal with a lot of traffic. If you have a complex data structure or a lot of sophisticated authorization rules, things may not be as cut and dry. There are a lot of benefits to using it, and in our opinion, they often tip the scales in favor of Firebase. That said, there might be other compelling reasons, such as a desire to version your API, increase security, or integrate with other platforms, where it would be more advantageous to create a custom API on your own server instance.