Switching from Parse to Firebase
When work initially began on Conversations, the choice of a backend provider was simple, Parse. It had everything we needed to get our app up and running in no time. Push notification support, scalable databases, static hosting, amazing analytics, support for cloud code, support for all the major platforms and it was supported by Facebook so I expected it to be secure and dependable (I have never been so wrong in my life). Work went along well and we got really dependent on the tools that parse provided like their implementation of file hosting and querying for data. One day, out of the blue, I receive a mail letting me know that Parse is shutting down and that we have one year to migrate all our work on it.
Needless to say, the team was crushed and the daunting task of porting all our all our code over to another backend provider loomed over us. At this point, we were left with a couple options:
- Set up a server using Node.js, and a database using MongoDB and start writing code for authentication, communicating with the database, file management and find an API provider for push notifications.
- Use another existing backend provider like Microsoft’s Azure, Google’s Cloud Platform or Apple’s CloudKit, but they were all streamlined for a single platform and they weren’t really useful for a multiplatform solution.
- Create a custom installation of the Parse server on a server that ran Node.js and continue work with the app like nothing happened with the exception of analytics and Push Notifications. (But we decided on not going back to Parse after pulling out the rug from under us)
- Use the firebase platform that’s supported by Google which has static hosting and user authentication but no push notifications, analytics or cloud code.
In the end, we decided to go with Firebase, because it had a key feature that would greatly help us going forward, an amazing realtime database and really cool offline features. We didn’t have to poll for new information anymore, or wait for a push notification to refresh our feed, as new information was added to the feed, it was just pushed to all users online and without refreshing, you could see new messages, that just sounded uber-cool and so we began the hard job of porting all our code over to firebase.
In the beginning, it looked simple, there is not going to be any cloud code, so all the code for querying, data verification and file management would have to be written locally on any platform we were working on (iOS, Android and web). We would have to rewrite our schema for the data store because even though both Parse and firebase were No-SQL databases, Parse used a more SQL like representation with rows and columns whereas firebase used a more JSON structure with objects and no way to query data (more on this later). All our authentication code would also have to be based on the firebase APIs and the way we store our files changed from the API method provided by Parse to encoding it into a base-64 representation and storing that as children of an object. This part of the port was trivial and was done in no time.
When the time came to create friend-friend relationships and to query users to find new friends, we found one major shortfall of firebase, it had no support for querying the database based on any attribute of an object. We could order by a key in our objects or limit our searches to a fixed number or check for the equal to query but it gave us no way to use the SQL “like” commands to find users based on searches like we were used to.
We are still working on finding a way to query and we might have to setup a server that could index all our database objects to run queries on it, or we might have to give up on queries and find an alternative method based solely on the tools that firebase provides. But whatever option we take, we hope it’s the right one.