Integrate with Firebase Storage

[omoki]

Hi. Will there be an AngularJS binding for firebase storage or should I use the vanilla firebase api?

[jwngr]

Changing title to make this issue a bit more permanent.

We don't have anything built into AngularFire to support Storage at the moment, so you should definitely use the vanilla Firebase API for now (Storage docs are here). It's unclear if we will ever add anything special to this version of AngularFire with regards to Storage, but we will probably add something to AngularFire2 at some point.

I'll keep this issue open to track support for Storage in this library. If anyone out there wants to see it happen, click on the emoji reactions above my comment. Please try to avoid doing a "+1" or "me too" comments unless you have something to add to the conversation like an API proposal.

[omoki]

Thanks for your response. With file events, I'm assuming I should manually call $apply(). Since everyone's probably new to the file storage api, are there anything else to keep in mind when integrating with angular?

[jwngr]

I haven't used Angular and Firebase Storage in combination yet to be honest. I've actually never done anything with images in Angular. I definitely assume you'll have to manually get the digest loop to run via $apply() or $timeout() or the like.

Hopefully someone else in the community can share some more concrete ideas though!

[davideast]

@omoki @jwngr

I've been experimenting with AngularFire2 and Firebase Storage locally, and it's given me some ideas for AngularFire 1.

If everyone is interested I could spend some time integrating the two together here.

There's two important bits for AngularFire, upload/download tasks and a gs://url directive.

Upload/Download Tasks This would be a simple wrap of of the Storage API, but it's necessary for monitoring the uploads and downloads.

Directive This feature would be awesome. You could use a directive rather than worry about programatically downloading the URL or knowing the unguessable URL.

<img fir-storage-url="gs://users/1/profile.png" />

This would cut down on a lot of code!

[omoki]

@davideast that would be great. Perhaps using a promise along with progress/notify to track uploads. I think the new storage api provides this via snapshot.bytesTransferred. I am currently using a custom server-side solution to upload to Amazon AWS and it was a big headache building a directive that handles different file types. There's just so many things to take care of. I'm also handling transcoding server-side and am keeping my fingers crossed that Firebase will also include transcoding capabilities in the near future. This will get me very close to zero interaction between client and my private server.

A directive (which may be out of scope for AngularFire) would set the stage for the next iteration of Firebase API. If the Firebase team doesn't stop at providing data storage (I hope not), then they will be expanding into the territory of other companies (e.g. Filepicker). Then Firebase will provide an API for handling different file types such as cropping, transcoding, etc. Maybe AngularFire will introduce methods like $firebaseStorage.$imageAction('resize', 500, 500).

And your directive would include other properties such as resize: <img fir-storage-url="gs://users/1/profile.png" resize="500x500" />

[omoki]

@jwngr By the way, I should add that when I posted this, I had been waiting for the new release and anticipated that there would be a new $firebaseStorage object in the api. I'm aware that angularfire never included 100% coverage of the vanilla api in the past.

However, if the storage api will not be supported by angularfire, then I think this would set a new philosophical direction in your development. Am I correct in thinking this? And if so, would you kindly provide guidance as to the scope of the project?

I'm also wondering if I should start to migrate to Angular2. I haven't had a chance to really look at it yet, but it's my understanding that this kind of manual digest cycle is no longer necessary with non-angular events in Angular2.

I'm basically wondering if you are starting to phase out of support for Angular 1 and treating it more like legacy support which is understandable.

[katowulf]

AngularFire was built primarily as a tool to help synchronize arrays and objects to your views, and to assist with authentication and routing. It will continue to do so. It's perfectly reasonable to consider storage as part of this mission.

Angular 2 is not yet out of beta and the Firebase support (i.e. AngularFire2) is still fairly experimental. It doesn't yet include support for the Firebase 3 SDK. These two platforms are both changing rapidly in parallel, so it takes a while for the synchronized tools like AngularFire to catch up, and really requires stable versions to do so. Thus, AngularFire 1 will be around for some time to come.

One thing I would note here is how quickly we were able to upgrade AngularFire compared to AngularFire2. A large factor here is simply that AngularFire2 is still experimental and not as well oiled yet, but partially because AF2 is more ambitious. Part of AF1's success has been its focus and simplicity.

So we would need to consider carefully how storage affects that, and whether it would be better served as its own tool before getting too far down this path.

@omoki This is not a new philosophy. The mission of AngularFire has remained purposefully focused. Also, you're pretty much on the cutting edge here, talking about new versions of Firebase with new (beta) versions of Angular. If this is a production app, you'll want to slow up a bit. If not, forge ahead and submit some PRs along the way.

[jwngr]

@davideast - Proposal looks good to me. As I mentioned, I haven't played a lot with Storage, so I don't know exactly what can of "Angular magic" we can inject in it, but both of those suggested items seems like good ideas. Handling the $digest loop automatically and simplifying URL management are great. Maybe @mcdonamp can comment on if these make sense since he is quite familiar with Storage even though he doesn't have a ton of Angular background.

@omoki - As Kato mentioned, I wouldn't call this a shift in the philosophical direction of AngularFire. We have limited resources and want to invest in where developers are going. It's always been this way, and for a long time, AngularFire did not include any authentication methods, just the database. So, Storage not being included is not that much different. Plus, Storage just came out two weeks ago and we need to see what pain points people have before we can solve them in AngularFire.

As for Angular 2, @davideast is working closely with that team and it is clear that is the future of the framework. Without limited resources, that seems like the better investment at this point. AngularFire for Angular 1 is still alive and well (as can be seen by all the activity here), but it will probably see more maintenance and less investment that AngularFire2 for Angular 2 in the same way Angular 1 sees more maintenance and less investment from the Angular team than Angular 2 does.

[asciimike]

+1 to the directive for gs:// URLs, this will provide download auth checks and is generally in line with best practices. I have no idea what the upload/download thing is, but if we can easily expose a progress bar interface for uploads/downloads, that seems like we can successfully reduce boilerplate :)

@omoki Long term, we'd like to natively support resize/crop/filter etc. a la: <img fir-storage-url="gs://users/1/profile.png" resize="500x500" />, and you can do some of it client side, but that's going to be a ton of work for now and it's probably better if we punt.

We're planning on integrating Storage with FirebaseUI on Android and iOS, so I could see us surfacing similar concepts in the Fire libraries for web components, primarily around wrapping gs:// URLs. Very long term, I feel like the Fire libs are parallels for the FirebaseUI libs, and can provide opinionated bindings for relevant Firebase features to the various web frameworks--but as has been mentioned, we don't have a short term strategy fully worked out as there are few of us and lots of JS frameworks ;)

[jwngr]

Thanks @mcdonamp! FYI that the upload / download thing is just tying the progress / completion / failure events of the vanilla Storage API into the Angular $digest cycle so that your Angular view updates when an event occurs. By default, Angular won't update your view unless you tell it to. So we can mirror what we do with the Database API and force the Angular view to update so that developers don't have to do it themselves.

[omoki]

@mcdonamp That's all great news. Thanks for the update.

@katowulf Thanks for the info. This does answer my questions and in that case would make sense for angularfire to provide angular bindings for storage events in the near future. I'm of course being as greedy as possible since understanding your intensions allow me to code with the future in mind :) But I do appreciate all of your hard work and am very happy to see new features added.

[davideast]

I'm closing this issue but opening up a new one with the API proposal. Feel free to comment there 😄

[rajeshnagireddy]

@davideast can you share new one link here