back
22 comments
I've been using Firebase in an Angular app I've been developing for the past couple of months, but instead of using AngularFire I rolled my own wrapper for a few reasons:

1. I didn't like how Firebase is explicitly injected into and referred to in the controllers. I don't want my controllers to be so tightly coupled to Firebase.

2. There was no support for associations. If you want to have object associations, which most non-trivial apps require, you need to manage all that complexity in your controllers using AngularFire. I wanted a solution that handled it implicitly, ala ActiveRecord.

3. I wanted additional features handled for me by the wrapper like timestamps, save/create/delete/init callbacks, collecting resources into stores to be used across controllers, etc.

4. AngularFire leans pretty heavily on Firebase as the place data is stored. I wanted to instead have my data stored in memory and automatically synced to Firebase without me having to worry about it. That way, if I ever switched away from Firebase I don't need to change any of my controller code.

5. Pagination is something that becomes very important as you start to build more complex apps, and it's not the most pleasant thing to deal with in Firebase at present. I wanted a wrapper that managed all those details for me.

Angular and Firebase are a great match, and AngularFire is a good way to get going quickly, but it lacks the features and depth required to make a truly complex application IMO. I had been meaning to throw my wrapper up on Github for a while so I suppose now is as good a time as any:

https://github.com/marknutter/firebase-resource

Examples and tests forthcoming.

That looks really nice!

I'd note that it is possible to wrap angularFireCollection into its own service if you'd like to keep that stuff out of your controller, for example: https://gist.github.com/jaredwilli/5472340

We went with an API that is easy to get started with, but are certainly committed to making sure its also usable by complex apps.

I think it was smart to focus on ease of use initially.
I've been working on a project with AngularFire for the last few weeks, and you just outlined every single issue I've had with the library so far. Associations were presenting a lot of complications especially. Thanks for sharing!
Their decision to dump the data right into the controllers and not have some interface with services always puzzled me too and was the reason I rolled my own instead of using angularFire.
I've enjoyed experimenting with AngularFire, but your wrapper addresses a couple of my concerns (#1 in particular). I look forward to taking it for a spin. Thanks!
I was just about to do this, very nice I'll be trying it.
I've also just begun to incorporate Angular into a number of my projects. I must say that without AngularFire and Firebase, I would have been helpless with regard to finding a good starting point - and the ability to develop apps quickly and painlessly in order to provide me with instant gratification.

That been said, in around 2-3 weeks, I've managed to incorporate AngularFire/Firebase into an MVC4 web app (which handles user accounts more securely) and allows Firebase to do what it does best - real-time updates to the users' UI.

The site, http://www.whereubeat.com tracks users' locations in real-time and provides an animated UI that acts as a homing device when trying to find your friends at a concert, festival, or sporting event. I would still consider myself a novice in both javascript and MVC4/C#; however, I was able to produce results soooo quickly using AngularFire/Firebase that I couldn't stop!

All that being said, I am aware that there are shortcomings with AngularFire/Firebase; however, let's face it... simplicity will always result in functionality shortcomings. Personally, I'd rather spend my time painting the canvas as opposed to stretching it myself.

I used AngularFire to build my application BringTheSalsa (http://bringthesalsa.hswolff.com/). Not only was it a pleasure to use, it also works beautifully. ++ to AngularFire.
I have Leaflet.draw set up to annotate tiled images of objects at a museum.

The annotated regions pass thru angularfire as geojson. Put 3 screens side by side. As soon as someone adds an annotation on one of them it pops up instantly on the others. This was < 20 lines of bad-I'm-new-to-angular code. Firebase is cool.

I agree with some of the negative comments (as of a month ago). I found a phonegap/angular/firebase app of mine kept crashing when angularfire was injected, so I just hand-did the requests.

The good thing is that firebase and angular are good enough that I was able to hand-wire things in like 5 lines.

Fix your bugs and your server stability Firebase. Using AngularFire for 2 months and it's alpha quality.
I've been using Firebase for 4 months and the stability has been pretty great. At least, no worse than I expect for a service this new. I had maybe 4 or 5 times where my site was slow or didn't load and never lasting more than an hour. Pretty decent uptime for 4 months or so. Note, I don't use AngularFire.
AngularFire is alpha quality, I'm definitely dumping it. On server stab it's not abjectly unusable but it's definitely not confidence inspiring. I had 4 or 5 times server problems lasting for hours in 1 week (though I think that should've been a 1 time thing), numerous other slow down events throughout my 2 months using it though.
We made a series of changes with version 0.3 of angularFire. It's nowhere near production ready but we're hoping its a bit more closer to beta than alpha :)

I urge you to give the new version a spin, and I really look forward to your feedback!

For some reason I thought this was an article about AngelFire and I got all nostalgic :\
Your website is crashing because of while (true) { $('form').submit(); }. Throttle that beeyotch.
After the visibility on HN the demo is crashing our browsers :)
that page crashes my chrome.
I'm using Faye (http://faye.jcoglan.com/) for pub-sub to an Angular front end. It is simple to use, performs well, and doesn't require replacing your existing toolchain.
How does it compare to socket.io or sockjs?
Also using Faye here, love it!