Version 6: Let's talk about easier communication system between Dart and Rust

[LucaCoduriV]

Hello, I'd like to share an idea to enhance this project. Protobuf provides services that enable the creation of functions primarily used with gRPC. I think it would be cool to be able to use it to call functions between Rust and Dart. I quickly looked into it, and it seems that Prost for Rust supports this, but I haven't checked the Dart side yet. If you think it's a good idea, I could delve into it further and possibly assist in implementing it.

[temeddix]

Thanks for the idea!

Yes, Protobuf does have 'service', so I considered using those inside Rinf. However the full support for it wasn't quit obvious on both sides of Dart and Rust. Maybe we can keep this as an idea, for now :)

[LucaCoduriV]

Good for me. In the meantime, I checked for dart and it seems that to make it possible there is no choice but to fork the project. It will need a lot of work.

[temeddix]

Hi @LucaCoduriV , maybe we can discuss this project further. I do agree that if we use Protobuf services, instead of something like RustRequest, it can be easier to write code.

• https://github.com/hyperium/tonic/blob/master/examples/helloworld-tutorial.md

I'm planning to make a new branch for experiment and development. If this change turns out to be easier and cleaner than the current system, we might be able to merge it in the next version :)

[thlorenz]

I am currently using rinf for a project (https://luzid.app) which has a Flutter UI via Rinf but also needs to allow controlling the Solana Validator via an SDK, i.e. scripts.
While looking into supporting this and reusing the Rinf types I also learned hat tonic provides you with a service interface and with tonic-reflect you can even get intellisense in Postman (and similar tools) while figuring out GRPC requests. (https://blog.postman.com/postman-now-supports-grpc/)

This is all to say that I'd also love to see something like this integrated into Rinf as then the API implemtantation for the Rinf message handling and that GRPC server would be almost the same.

Also the CRUD idea may make sense in some scenarios, but for an app where I basically want to do RPC style function calls the REST pattern gets almost in the way (I just picked whichever Read/Create/Update and repurposed it for what I actually needed).

Also to facilitate reuse of the generated proto types (in my case for the GRPC server/client) it'd be useful to override where rinf writes those Rust definitions, so they can be exposed via a core crate (instead of the server having to depend on the hub crate to get to them). Basically 'native/hub/src/messages' on this line needs to be configurable via a command line arg.

I'm gonna provide a PR for that tomorrow so we can get there step by step assuming this is something you want to add.

Finally I wanted to say great lib! I attempted something similar a while back rid, but went too far trying to provide all boilerplate and a simple API. However that got super complex quickly and I find the solution to use protobuf instead a very elegant one!

[temeddix]

Great! If we do this experiment, these think would be important:

• Easy: Users shouldn't be required to write too much more code than the CRUD system right now.
• Maintainable: Without a logic that's too complex for ourselves to understand.

I've been taking a look at tonic too, and maybe we should be able to answer these questions:

1. tonic server seems to use HTTP/2, which has too much overhead when compared to native FFI. Should we implement the FFI server(that doesn't use HTTP) ourselves?
2. With tonic, Protobuf services becomes Rust traits. Should the user write their own structs to impl this traits, or can we provide a simple codegen mechanism for that?
3. Should each of Protobuf service get a different ABI, in other words, the extern "C" fn?
4. How will 'streaming from Rust to Dart' work, without any first request from Dart?

I'll be happy to accept any kind of ideas or PR, and possibly merge it into the next version if it looks okay. Thank you very much for your participation! I'm looking forward to seeing your solution.

P.S. Thank you for choosing Rinf! If you enjoy it, please consider letting others know if they're looking something like this :)

[thlorenz]

Just wanted to post the solution I currently came up with. https://gist.github.com/thlorenz/6b16d0a9f2202df6c149cc2095c695ab

It includes the build.rs I'm using + a sample proto file and the resulting generated rust.

It's a three step process:

1. Run rinf and have it add the messages to my grpc crate that has tonic as a dependency
2. After capturing rinf generated ID, run tonic to generate the same files again which then includes the service definitions
3. Append the captured rinf ID to the end of the tonic generated file

To be clear the service is used only when running this as a separate GRPC server. The hub and rinf requests still work as before, only that they now use the rust types that are inside that grpc crate.

[temeddix]

Maybe we can declare messages just like before, but only let go of the CRUD concept, and implement a very simple code generation mechanism.

So that this Rust function

#[rinf::interact]
async fn test(message: MyMessage) -> MyReturn { }

becomes this Dart function

Future<MyReturn> test(MyMessage message) async { }

where MyMessage and MyReturn is declared in a .proto file.

Your example looks interesting and respects to the amount of thoughs went into it. However if we want to make it 'efficient' enough, we should not use HTTP for communication for this. We can organize ideas and brainstorm more here :)

[temeddix]

If we decide to provide a simple codegen mechanism like that, a parser library might be needed to analyze Rust code.

Tree-sitter

• https://crates.io/crates/tree-sitter
• https://pub.dev/packages/tree_sitter
• https://tree-sitter.github.io/tree-sitter/playground

PetitParser

• https://pub.dev/packages/petitparser#using-grammar-definitions

I have come up with some ways to make this work, being focused on simplicity, efficiency, and maintainability. If the above idea looks okay, it might be possible to make this happen in not-so-distant future.

Anyone who has opinions, please leave your thoughts here!

[temeddix]

Currently, a big work is being undergone to make the communication system way easier. There's a new simple codegen mechanism, and the basic idea is as follows. // [RINF:DART-SIGNAL] and // [RINF:RUST-SIGNAL] comment marks the message as communcation channel, so that the codegen can understand that it should provide additional mechanism for them.

From Dart to Rust

// proto

// [RINF:DART-SIGNAL]
message DataInput { ... }

would allow us to do

// Dart

dataInputSend(DataInput( ... ), null);

and

// Rust

let receiver = data_input_receiver();
while let Some(data_input) = receiver.recv().await {
    // Custom Rust logic here
}

From Rust to Dart

// proto

// [RINF:RUST-SIGNAL]
message DataOutput { ... }

would allow us to do

// Dart

dataOutputStream.listen((dataOutput) {
    // Custom Dart logic here
}

and

// Rust

data_output_send(DataOutput{ ... }, None);

---

This is a breaking change, but I believe it's worth it because it's so much easier to define new endpoints. Sending and listening to messages is much easier and more intuitive than before.

It's being developed on event-driven-communication branch and it is already working quite well. You can try it out by cloning the branch on your machine.

• Event driven communication #270
• https://github.com/orgs/cunarist/projects/19

I'm just polishing things and improving code to ensure safety, so it will be in the beta phase for a while. We can make breaking API changes during that time. Any opinions are welcome :)

[temeddix]

@bookshiyi , may I ask if this change seems okay, or if there's a room for improvement?

[bookshiyi]

Hi @temeddix, it is a great idea as it significantly simplifies the development of code for sending and receiving messages.

Additionally, I am unsure whether the REST-style API will be retained. When writing Rust programs, using tools similar to a postman for debugging/generating API documentation is also great.

[temeddix]

Thanks for the fast reply :) In this case, the REST-style API will be deprecated(for good reasons, in my opinion). There would be only two-way channels left.

Speaking about documentation, our system is different from typical HTTP APIs, but I'll definitely take a look into your postman idea and find what we can learn from them. If I missed something, please let me know. Personally, I do think that doc comments written right inside Protobuf files can be a really good documentation while developing.

// [RINF:DART-SIGNAL]
// This is an audio data sample of...
// contains...
// responsible for...
message DataInput { ... }

[VictorieeMan]

I'm guessing this is what's in the 6.0.0-alpha? I've tried both the old implementation and this new way now and my experience is: Much better! I redid my whole rinf implementation in my project using this 6.0.0-alpha and I'm very happy about it :)

Feedback on good work!

[temeddix]

Thanks! Rinf version 6 beta will be released in 3 days, and the API is expected to be even simpler. Please hang on :)

[temeddix]

Rinf 6 beta is out, and the API is fixed. There should be just a bit more polishing and gathering bugs from people(if any).

Rinf 6 should be much easier to use. Documentations are also updated. If anyone finds out some unexpected bugs, please let us know!

• https://rinf.cunarist.com/messaging/

[VictorieeMan]

Great news! Love the work on this :)

On the bug issue, I did an attempt on compiling my flutter-rinf app to an android apk file and there's some bug in loading "dynamic libraries". I need to do some more testing, not sure if it's a flutter or rinf bug just yet. But I imagine rinf could be the "dynamic library" its refering to.

Running 6.0.0-alpha, will do further testing on this new beta!

[temeddix]

Okay, I will check running on Android, thanks for the report :)

[temeddix]

By the way, would you try this on your project and check if it helps?

• https://rinf.cunarist.com/frequently-asked-questions/#i-encounter-an-error-related-to-loading-native-libraries-on-older-android-versions

[VictorieeMan]

By the way, would you try this on your project and check if it helps?

* https://rinf.cunarist.com/frequently-asked-questions/#i-encounter-an-error-related-to-loading-native-libraries-on-older-android-versions

Yes I did give this a try, but it didn't solve the problem I had.

^^ Today, I can redo my attempts using the 6.0.0-beta and report what happens in a github issue, so that the problem gets easier to track :)

[VictorieeMan]

The issue will soon be up, I just started working on my testing :)

btw, what is the easiest way to update the rinf version in an existing project? I assume that for updates without breaking changes it's enough to just update the versioning number in the pubspec.yaml file.

[temeddix]

For major updates, it requires rinf template. For example, 5.x>>6-alpha.

For minor updates, it only requires rinf template --bridge. For example, 6-alpha>6-beta.

[VictorieeMan]

cool! thx!

[temeddix]

Glad to help! If you've enjoyed Rinf 6, please let other devs know Rinf as well later :)

[VictorieeMan]

ofc!
^^ After building some stuff I'll write about it on Medium

[akhudek]

I'm still on v4 and just looked at v6 today. For my application I'm having difficulty seeing how use the new design without immense amounts of boilerplate and major redesign.

The way I've been using rinf is mostly via RPC style calls. On the dart side I've wrapped all the rinf functions in simple async style calls. So, for example, if I want to read an object from a database on the rust side, I usually just make a read call with an id.

class ThingOp {
  static Future<Thing> read(int id) async {
    const rustRequest = RustRequest(...);
    ...
    final responseMessage = thing_pb.ReadResponse.fromBuffer(
      response.message!
    );
    return responseMessage.effect;
  }
}

This is easy to use in a button callback or the like, where the callback just sets state in the right place. With the new design, however, now I need to put a whole bunch of StreamBuilders into my build tree, which doesn't fit nicely at all with flutter state management.

Worse, if I wanted to have two widgets both reading/updated 'thing's on the same screen, the new signal design would require every streamBuilder to have a filter so that it only gets the things with the id it is managing. This is a lot of extra code and complexity compared to before.

I think there is a lot of value in having standard RPC style design patterns out of the box, rather than having users try to recreate them with complex streaming like in v6.

Or perhaps I'm missing something and there is an easy way to achieve RPC besides the example in the document? One that doesn't require a streambuilder embedding in the build tree and can work with a simple async call?

[ArinFaraj]

I'm currently doing this and it works, I haven't tested the performance impact but i needed to do something quickly

Future<void> doSomething() async {
	final uid = uuid.v4();
	
	Input(
    	uid: uid,
    	data: data,
  	).sendSignalToRust(null);
  	
  	final response = await Output.rustSignalStream
  	  .firstWhere((e) => e.message.uid == uid)
	  .timeout(Duration(seconds:5), () => TimeoutErrorOutput());
}

but remember to send the uid back with the output in rust

[temeddix]

Great example, @ArinFaraj ! I'll add this idea to the docs.

[temeddix]

Hi @akhudek, thanks for sharing your opinion.

It looks like the new system doesn't work very well for you.

This decision was made to remove the big with_request.rs and the handle_request() function, where you had to add up the request handler function over and over again which results in a bloated global handler. We only provide raw channels because we want to minimize unnecessary abstractions.

Also, storing states on the Rust side with OnceLock and HashMap might be beneficial when Rust is taking care of the business logic, while Flutter simply shows the content on the screen.

Worse, if I wanted to have two widgets both reading/updated 'thing's on the same screen, the new signal design would require every streamBuilder to have a filter so that it only gets the things with the id it is managing. This is a lot of extra code and complexity compared to before.

It is true that you need to filter signals by some kind of id field, but the amount of code required should be smaller than handle_request() function and writing each handler function like handle_numbers() with match statements on the Rust side. Perhaps giving each widget or class instance a key would work. There's a good example project where they're doing exactly something like that

• https://github.com/kodjodevf/mangayomi