Firebase is an awesome backend API that allows developers to build apps without managing servers. Among the killer features of Firebase is its push ala socket.io, but really, there is more than that. So far, these are some Firebase features that I have personally used:

• Push data from an Angular.js client
• Store data in a Firebase data structure
• Receive data on an Android app

Yep, data was sent from an Angular.js client to an Android app because Firebase supports multiple client platforms. As far as I know, they have client libraries for:

• Angular.js
• Android
• Java
• Objective C
• Javascript

How to Get Started

A Development Firebase is free. You can get started right away by signing up, and then creating a Firebase backend.

How to Use

As much as I’d like to simply point you to their developer documentation, I think I’m still obliged to write a simple code example because c’mon, a tech blog without code samples? But really, the Firebase team did a great job in their docs.

Here’s how you push data from a JS client:

Simple wasn’t it? And here’s how you receive data on an Android client:

While the usage itself is simple, there are some caveats to keep in mind. In Android, DataSnapshot::getValue() will either return an ArrayList or a Map, depending on the kind of data that was stored in Firebase. If it is a collection, it will be an ArrayList of Maps, otherwise, it will simply be a Map. In addition to this, you can’t use generic types for those collections because Firebase doesn’t restrict the data types that it can store.

Yep, it’s that few lines of code.

What is it good for?

In Android/iOS, you can totally eliminate the “Pull to Refresh” UI pattern commonly being used in mobile devices. With Firebase, there’s no need for this since the data will get pushed to the device as it becomes available. In my experience at least, a Firebase listener is far easier to implement than pull to refresh. In theory, you can also replace GCM/APNS with Firebase, as long as you put your listener in a long running service. Well, in Android at least. I don’t know about iOS since I don’t have experience developing native apps in that platform.

Since Firebase is a full backend, you can get away with not implementing your own backend as long as you’ll only be sending/retrieving objects. If you need to manipulate the data server-side, then you’ll have to supplement Firebase with your own backend. This makes Firebase an ideal choice for hackathons, and for quickly prototyping frontend stuff.

When not to use it?

If you have a rather large app and you’re on a budget, or if you want to do a lot of data manipulation/computation on your backend which might require advanced database features like triggers. Aside from that, I can’t think of anything else because I haven’t explored enough of Firebase to know its quirks.

Overall

Firebase is awesome. It’s now my default choice for “Pull to Refresh” (not really, because push) UI patterns, and for hackathons. I haven’t tested my GCM theory, but I’m also keen on replacing GCM with Firebase. I’ll do experiment on that as time allows. Overall, Firebase is a worthy tool in my toolbox.