1. 9
  1.  

  2. 6

    I’ve been using Firebase at work recently (and liking it, a lot).

    Misconception #1: Firebase is client-side only

    I vehemently disagree with the first claim, that Cloud Functions fix Firebase’s “being client-side-only” problem. To quote the giant warning right at the top of the documentation:

    This is a Beta release of Google Cloud Functions. This API might be changed in backward-incompatible ways and is not subject to any SLA or deprecation policy.

    “not subject to any SLA or deprecation policy” is not a pleasant phrase. I’d rather punch myself in the face than ship code that relies on a feature with no SLA whatsoever. Imagine being called up at 3am by a customer because your product is completely broken in prod and the root cause turns out to be that Google removed or changed a feature without any warning whatsoever just like they said they would and don’t plan to change it back. That would suck.

    You can connect more than one application to the same database. I don’t believe there’s anything stopping you from running a second app on a nice shiny Xeon server that connects to your FB account once in a while and runs a big clean-up action or whatever, rather than having to do that on phones or in web browsers.

    Misconception #2: Firebase results in spaghetti code

    Agree, it’s mostly lovely.

    My experience so far, working with Firebase in React, has been that every single piece of code that explicitly called firebase.database().….once() to perform a query about anything sucked, but every single piece of code that called firebase.database().….on('value', snapshot => this.setState({something: snapshot.val()})) to watch a tree worked delightfully with no spaghettification at all. That’s a word now because I said so.

    A consequence is that I can’t quite bring myself to love the firebase.auth() module because it’s missing subscription functions for a couple of the things that you can query from it.

    Misconception #3: Dumb data modelling / too much duplication

    I think suggesting that denormalisation isn’t a hack is silly. It’s the kind of hack we can live with, though. IME Firebase seems to encourage flattening data more than it encourages denormalising data. The atomic multi updates thing is super useful (and I’m glad I haven’t needed it before now).

    Misconception #4: Firebase can lead to data inconsistencies

    Yep.

    Except for where you have multiple concurrent writers touching the same objects. Firebase’s semantics around isolation are necessarily really astoundingly loose because Firebase continues to work when you’re offline (killer feature!).

    I’d very strongly advise trying to arrange your data model so that there’s probably only ever one client at a time who would plausibly want to update any given object.

    Misconception #5: Very limited querying capabilities

    I agree that querying is less limited than you’d expect from a cursory reading of Firebase’s docs but it’s still very very limited. It’s still perfectly possible to write useful, valuable applications that make money without using interesting queries. For applications that are 95% CRUD, the one thing I really miss from Firebase right now is some kind of full-text-search. Even a half-assed implementation.