Skip to content
This repository has been archived by the owner on Sep 7, 2022. It is now read-only.

firebase-dart/FlutterFire abstraction #170

Open
davidmarne opened this issue Apr 2, 2018 · 10 comments
Open

firebase-dart/FlutterFire abstraction #170

davidmarne opened this issue Apr 2, 2018 · 10 comments

Comments

@davidmarne
Copy link

It would be great if firebase-dart could collaborate with FlutterFire to agree upon common interfaces, in which both packages implement.

I'm working on a project where I am building a web app and a flutter app, and I am trying to abstract the common business logic into another library for both apps to consume. As it stands right now I have to implement a lot of things twice, once for web and once for flutter, and the logic is almost the exact same each time.

Would it be possible to agree upon common interfaces that both libraries could implement?

Would it maybe make more sense to write another library that wraps both libraries to implement a common interface? I've thought about doing that but it seems like a lot of manual, boring work. Plus it would be difficult to maintain.

@kevmoo
Copy link
Contributor

kevmoo commented Apr 2, 2018

I 100% agree. I've mentioned it before to those folks. Please file a companion issue here and reference this?

@davidmarne
Copy link
Author

they don't appear to accept issues from the community over at https://github.com/flutter/plugins :(

@kevmoo
Copy link
Contributor

kevmoo commented Apr 3, 2018

they don't appear to accept issues from the community over at https://github.com/flutter/plugins :(

See the readme. File issues here: https://github.com/flutter/flutter/issues/new

@rrousselGit
Copy link

I'll admit I started something mininal on my own this w-e (a wrapper interface instead of editing this plugin sources).

So if needed, I can help

@sidgo28
Copy link

sidgo28 commented Jan 7, 2019

Any news on this? Because I believe this should be prioritized (at least firestore) given that there's practically no alternative to firestore when developing apps with dart.

We're developing a cross-platform app with flutter for mobile, angular dart and electron for desktop, and right now we have no choice but to implement our own wrappers over the two APIs (which is silly given that the two APIs are practically similar plus the fact that they both come from the same organization).

Also, based on our experience, I believe it would only take a miniscule amount of time given the similarity between the APIs and the size of the firestore library. You only need to factor out at least the important APIs to a common interface then maybe expand it later.

@sidgo28
Copy link

sidgo28 commented Jan 7, 2019

Plus the terrible thing about this is the two APIs diverge more as time goes by and the task gets messier (not just for the Google engineers but also for the consumers of these two redundant versions of the same product).

@kevmoo
Copy link
Contributor

kevmoo commented Jan 7, 2019

No details here. It's absolutely no my radar, but I'm not planning to push this for a while.

If someone in the community wants to take a stab, I fully support it!

@cbenhagen
Copy link

cbenhagen commented Aug 18, 2019

You might also take a look at the crossfire package which provides a common API for the FlutterFire plugins and the JS API Wrapper of the firebase package. It could definitely use some love though.

@Eddydpyl
Copy link
Contributor

You might also take a look at the crossfire package which provides a common API for the FlutterFire plugins and the JS API Wrapper of the firebase package. It could definitely use some love though.

I thought the same, and finally decided to implement my own thing, and work on it as needed. It's still far from complete and needs some work, but I have plans to finish it up: Fireblend

For now you will find some methods for Realtime Database, Authentication, Messaging and Storage.

@cbenhagen
Copy link

Please give a thumbs up on the corresponding issue in the new flutterfire repo: firebase/flutterfire#40

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants