4 ms·
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 fe
by marknutter 13y ago
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 https://github.com/marknutter/firebase-resource
Examples and tests forthcoming.
- alevans4 13y agoTheir 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.
- rch 13y agoI'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!
- KaoruAoiShiho 13y agoI was just about to do this, very nice I'll be trying it.
- anant 13y agoThat 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 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.
- marknutter 13y agoI think it was smart to focus on ease of use initially.
- awhitty 13y agoI'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!