I recently finished re-prototyping a product that used to use Firebase.
The reason I switched was because - no search. Or poor search anyway. Yes, I did use the Firebase Functions to monitor changes for data and yes I did copy ALL the data to Mongo so that I could actually run a capable search … but the overhead is TOO HIGH. I shouldn’t have to mirror my data and maintain those bridges (and support customers when the triggers fail to fire - yes, it does happen). And the permissions system in Firebase plain sucks IMHO. ACL is much more powerful and IMHO simpler.
So I switched to parse to have an all-in-one - but here are the two main ‘gotchyas’.
-
Parse can be finiky when working with nested data (setting and getting nested paths), which Firebase is really strong at, so you might might need a mental shift and data restructure here. It seems to want flat SQL like data but I’m a Mongo guy - I like nested data because to me its cleaner and more organized.
-
Data reactivity. It’s non-existant in Parse. If you are used to binding data from Firebase to a Vue or React-type application and having changes magically reflect through your application when the data changes from the view or a central store (eg vuex), it’s not going to happen. Getting anything is a
get()function which cannot be bound to reactive UI libraries … or proxied.
Frankly, with the popularity of Vue and React and such, I’m very surprised that the Parse community hasn’t created any reactive view of the underlying data.
In other way, Parse is a dream! Data modelling, relations, ACLs, cloud functions, and serach. Plus it can be self-hosted or commercially hosted from a variety of options (I choose Sashido.io). Its a great option!