Leverage existing crate to alleviate types conversion

[Roms1383]

Hello @thlorenz ! I stumbled upon this other project yesterday: flutter_rust_bridge.

My knowledge of rid's internals is very limited, almost inexistent, but from what I understood the notable difference is that rid works with safe pointers to provide informations back and forth to Flutter over FFI, while this crate seems to focus on providing safe types conversions.

But I wondered: could this be a nice addition to rid's dependencies ? It seems like they already cover some types conversions that are missing in rid, so to avoid reinventing the wheel maybe ? (I'm thinking about #52 for example)

If my reasoning is stupid, please let me know, I don't mind looking for a fool as long as I learn something in the process :)

on a side note, I think you could open the Github Discussions feature on your repo, to avoid bloating the Issues section with question like mine here.

Thanks :)

[thlorenz]

Thanks for pointing this out ... I wasn't aware of this project, seems fairly young (first commit in beginning of Oct).

Judging from this, there is definitely some overlap:

Unlike low-level binding generator which only provide primitives and pointers, this package provides things like Vec(Uint8List), Vec(List), any custom struct(class)s

I skimmed through the code quickly and think that the adapter works differently which would make it difficult to simply port some type implementations over to rid. If I understand correctly from this example generated rust code along with the dart generated it uses some wire mechanism to bridge Dart and Rust.

It's also different in the sense that rid provides an application API similar to elm/redux while flutter_rust_bridge is more about calling rust function directly and getting the entire result back (if the description is correct at least large Vecs don't need to be copied). It would require extra code to use it for state management for instance.

However it looks like a very interesting approach!

If you have the time and interest you should try to build a small example that you built with rid or one of the examples inside the rid-examples repo with flutter_rust_bridge and see how it works. We may learn a lot from that and see how we can integrate some ideas into rid.

However from a quick look I believe that under the hood it works very different from Rid.

This also brings some caveats, i.e. synchronous property accesses or method calls which are possible with rid's low level API are not possible with flutter_rust_bridge. However if you just used the high level Rid API the experience should be similar as if I understand correctly flutter_rust_bridge is able to provide Rust structs as fully instantiated classes to Dart.

[enzotar]

Not 100% related, but here is an interesting example of a project using Flutter/Rust:

https://github.com/AppFlowy-IO/appflowy

https://github.com/AppFlowy-IO/appflowy/blob/main/doc/APPFLOWY_SYSTEM_DESIGN.md

[thlorenz]

@enzotar let's collect those in the readme. That way we don't loose track and provide others that info. We can also think of adding a section like this to the docs ..

Could be a section like:

Related Projects

[Roms1383]

Yes indeed @thlorenz. To follow up @enzotar, AppFlowy just published a very interesting article about their design choices.

[Roms1383]

As it seems in the current state of progression rid surely achieves better performance than appflowy (not sure if compared with flutter_rust_bridge though, I lacked time for benchmark) since AFAIR it uses smart pointers-like bindings over FFI (here flutter_rust_bridge seems to provide more extended types support than rid though), as appflowy originally chose a gRPC based inter-communication and they describe some performance pitfalls in some contexts (see article).

On design level I would say that rid originally chose a more "Flutter plugin"-like approach, where communication was initially mostly meant to be Dart-driven (I'm thinking about the discussion we had earlier, especially related to async runtime), while appflowy went for the opposite way, a Rust-driven communication (I personally here think they made a great choice, since it allows to use Flutter solely as a presentation layer, which seems way more modular by design, see also article for details).

Well, please do correct me if ever I was incorrect, other feedbacks welcomed too. I'm personally very enthusiastic about these different projects and approaches because it will surely benefit the future Rust / Flutter ecosystem as a whole :)