Will/Should Firebase Plugins be implemented natively in Dart? #3359
-
|
The current plugins are all calling native implementations via platform channels. I would love to have a discussion on:
This discussion was already opened once here as a ticket but there was no answer from the FlutterFire team: Efforts made by the community for native implementations: |
Beta Was this translation helpful? Give feedback.
Replies: 10 comments 16 replies
-
|
One big plus for me as a user of these plugins would be to have easy integration tests with services like Firestore. Currently the only way (that I know of) to run tests using Firestore is via Flutter driver tests. Additionally, while I already have seen improvements with recents efforts of the team (thanks guys ❤️) there may still be a benefit to having a Plugin completely written in Dart in regards to build time. |
Beta Was this translation helpful? Give feedback.
-
I'd guess this was probably just the quickest way to get started with the least amount of work - still may be interesting to hear if native Dart was considered in the past. |
Beta Was this translation helpful? Give feedback.
-
|
Bringing in Raz creator of the firebase_dart_sdk above. /cc @long1eu |
Beta Was this translation helpful? Give feedback.
-
|
I would love this and I have thought about this a lot (like a lot, a lot) so here's my 2 cents on this (but its not an 'official opinion' or anything like that); While it certainly would be possible have some of the plugins in Dart there's quite a few that just won't be possible to do well (or at all) without using underlying native APIs, some examples;
Then you have ones like Firestore that have local first and offline querying capability built into the current SDKs (which is a huge amount of work to implement and to get right, I think) and that each of the current native Firestore SDKs are optimised well for each of their platforms. It could be done though, but it's an impractical amount of work I think. Option B) You could say 'ok how about some of the plugins built in Dart', which leads to problems like synchronising state between 2 SDKs (Dart and non Dart ones), e.g. imagine Auth is all Dart, but Firestore isn't, to get Firestore to work correctly on native with Authentication you'd have still use the native Auth SDK and somehow sync Authentication between the pure Dart auth SDK and the native Firebase Auth SDK so that the Firestore Native SDK still functions with auth. |
Beta Was this translation helpful? Give feedback.
-
Firestore and Auth have already been ported to Dart - take a look here https://github.com/fluttercommunity/firebase_dart_sdk/tree/develop/cloud_firestore/cloud_firestore_dart cc'ing @long1eu :) |
Beta Was this translation helpful? Give feedback.
-
|
Aye I saw, this is what I meant in general about offline/local support: https://github.com/fluttercommunity/firebase_dart_sdk/tree/develop/cloud_firestore/cloud_firestore_vm/lib/src/firebase/firestore/local Thats no small amount of code 😅 |
Beta Was this translation helpful? Give feedback.
-
|
Also to add, the Dart implementation would have to be absolutely battle tested and fully managed in case of critical issues / security etc. As a community project this is a massive amount of work. |
Beta Was this translation helpful? Give feedback.
-
|
@orestesgaolin just found myself discussing this point again elsewhere. I think another point to take into consideration is the upkeep of such a library. The https://github.com/fluttercommunity/firebase_dart_sdk repository now hasn't had an update in 8 months - such a library needs constant attention and upkeep to be viable. |
Beta Was this translation helpful? Give feedback.
-
|
Agree, and I think it's impossible either without huge community support or company standing behind that like Invertase with this very project. |
Beta Was this translation helpful? Give feedback.
-
|
Would like to add as well that we are making all plugins in FlutterFire federated as part of the roadmap. So the |
Beta Was this translation helpful? Give feedback.
-
|
I wonder if it's possible to follow the |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
Developement for
As of now the are a bit dated, especially firestore, but I am working to bring them back. |
Beta Was this translation helpful? Give feedback.
-
|
What were the biggest advantages for you? So why are you building the native SDKs instead of using the FlutterFire ones? |
Beta Was this translation helpful? Give feedback.
-
|
Except for not waiting 10 mins for ios to build firestore, the fact that they are compatible with desktop or any other platform that dart supports. |
Beta Was this translation helpful? Give feedback.
-
|
@long1eu just in case you missed it, I posted this a while back: #2751 Significantly improves Firestore build times on iOS :) |
Beta Was this translation helpful? Give feedback.
-
|
I think the best thing is that you might be able to run Firebase-based apps on sth like RaspberryPi or TV Box that otherwise wouldn't support it. Also, ability to actually debug the Firebase code is something we would love to have. The delight of being able to debug the Flutter or some packages could be extended to Firebase. |
Beta Was this translation helpful? Give feedback.
-
|
Having a native dart implementation in the future would be great. For now it would be enough if we could have dart APIs that all plugins/packages use. For us a firestore API would be very helpful. We have firestore dart code on flutter, angular_dart and cloud functions. At the moment we created an API (https://github.com/dartclub/firestore_dart/tree/master/firestore_api) and wrapper for flutter and web. Our business logic depends on our on API and we initialize the wrappers on the different platforms. |
Beta Was this translation helpful? Give feedback.
-
|
Indeed it would be great to move anything that can be dart, be dart. The advantages are pretty obvious if you're ever tried to build the native SDK on MacOS or iOS on many different projects and machines. Out of the box it's extremely slow, and you need jump through hoops to speed it up, and even then it complicates the entire build chain, and can often lead to cryptic and hard to solve build errors. And then there is the obvious cross-platform conversation, where native SDK are inherently non-portable, not working everywhere Flutter does, like Amazon, PI, Windows, Linux. So this approach is very much at odds with the goals of Flutter itself. So to recap: Native SDK's are: slow, complicated, non portable and flaky to build. On the other hand, things written in dart, are light weight, fast to compile and 1000% portable. To me the POV is backwards here. You're thinking native first, with dart where it makes sense. It should be flipped. Dart code strongly preferred and used wherever possible, native code only when strictly necessary, and fail gracefully when functionality doesn't exist on that platform. As an alternative for now, we have been looking at: https://pub.dev/packages/firebase_database_rest and https://pub.dev/packages/firebase_auth_rest but of course this requires moving all our data which firestore does not make easy (who needs database backups/import anyways! MySQL only had them for 2 decades :p ) |
Beta Was this translation helpful? Give feedback.
-
|
I totally agree with you, I'd love a Dart only package but it's simply not feasible (unless it's heavily invested in by Google themselves) in my opinion - even then packages like Messaging simply won't work. There are many complexities which the Firebase SDKs achieve, which Dart would have to fully replicate (think offline database caching with syncing to servers on network connection changes). It's possible for sure but it's a gigantic project. If it was also offered as a first-class SDK, it would have to be absolutely battle tested - right now a lot of the complexity is shifted to the already tried and tested existing SDKs.
This doesn't work well though in a real-life scenario. You've got native holding onto it's own state (e.g. an authenticated user), however you then have a scenario whereby some other functionality could be integrated with Dart-only. The two still need to interact with each other, and if not, you're going to have to write a full SDK for Dart anyway. I'm not saying it's impossible, I personally just think it's not worthwhile with the extra work this approach generates on it's own. On-top of this, you can't have a Dart-only SDK for say Cloud Functions and a native approach with Auth, since they directly work with each other (automatically authenticating requests etc).
I wouldn't say this is an alternative, it's a total different approach to using Firebase in your app. By using the REST APIs you lose the benefits of the native SDKs (offline, caching, performance considerations etc).
What makes you say they're slow? I'd like to see some numbers for comparison. I disagree with you on being complicated - if you're comfortable with native code then they're fairly straightforwards. |
Beta Was this translation helpful? Give feedback.
-
|
Right, to clarify, when your needs are Firestore and Auth, which in my
experience is the core value proposition of firebase, and the 2 features I
use most often by far, then this is a nice alternative.
The frustration with this conversation from dev perspective, is we're not
necessarily interested in all those advanced features, yet they are used as
rationale why we cant get the simpler more common API we do want. This is
why a dart first approach, with native extensions that are additive seems
like a far better long term approach.
Rather than:
* You cant use Features A or B, because C is not supported.
It would be:
* You can use A or B, bit C is not supported on this platform.
From a ignorant developer perspective, the forner doesnt make sense.
In terms of slowness, I mean primarily at build time. Including the native
sdks drastically inflates your build times on ios and macos, leading
directly to a loss in revenues and productivity (not to mention a large
decrease in developer happiness/joy). There are workarounds for this, but
even when using the precompiled binaries, builds are still fairly slow, and
add yet more links in an already complicated chain, which can lead to
weeklong cleaning/building marathons with very cryptic errors. Complexity
kills, and this adds a lot.
When you are only after a basic database connection and auth this is pretty
frustrating, cause you know that under the hood, were just passing json
blobs over the wire and it could basically all be done with REST, and youre
going through all this because of features you have no desire to use
anyways.
…On Fri., Apr. 16, 2021, 9:23 a.m. Elliot Hesp, ***@***.***> wrote:
I totally agree with you, I'd love a Dart only package but it's simply not
feasible (unless it's heavily invested in by Google themselves) in my
opinion. There are many complexities which the Firebase SDKs achieve, which
Dart would have to fully replicate (think offline database caching with
syncing to servers on network connection changes). It's possible for sure
but it's a gigantic project. If it was also offered as a first-class SDK,
it would have to be absolutely battle tested - right now a lot of the
complexity is shifted to the already tried and tested existing SDKs.
To me the POV is backwards here. You're thinking native first, with dart
where it makes sense. It should be flipped. Dart code strongly preferred
and used wherever possible, native code only when strictly necessary, and
fail gracefully when functionality doesn't exist on that platform.
This doesn't work well though in a real-life scenario. You've got native
holding onto it's own state (e.g. an authenticated user), however you then
have a scenario whereby some other functionality could be integrated with
Dart-only. The two still need to interact with each other, and if not,
you're going to have to write a full SDK for Dart anyway. I'm not saying
it's impossible, I personally just think it's not worthwhile with the extra
work this approach generates on it's own.
As an alternative for now, we have been looking at:
pub.dev/packages/firebase_database_rest and
pub.dev/packages/firebase_auth_rest but of course this requires moving
all our data which firestore does not make easy (who needs database
backups/import anyways! MySQL only had them for 2 decades :p )
I wouldn't say this is an alternative, it's a total different approach to
using Firebase in your app. By using the REST APIs you lose the benefits of
the native SDKs (offline, caching, performance considerations etc).
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#3359 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAFT5TMSTKPJQAEWIIDUOV3TJBI7NANCNFSM4QL25H2A>
.
|
Beta Was this translation helpful? Give feedback.
-
|
I would love to add to the "1000% portable" part. We talked about Linux and windows (with flutter), in my case I am using native dart with cloud firestore. In my use case the server is smart home hub/device that allow local connection control from the app, and remote connection through firestore. As @esDotDev said, I would love to see simplified implementation of the library and be aware that it will not get advance features that are over the head to implement like saving locally the data (not cache memory). |
Beta Was this translation helpful? Give feedback.
I would love this and I have thought about this a lot (like a lot, a lot) so here's my 2 cents on this (but its not an 'official opinion' or anything like that);
While it certainly would be possible have some of the plugins in Dart there's quite a few that just won't be possible to do well (or at all) without using underlying native APIs, some examples;