Tracking issue: Rust gRPC

[ian-p-cooke]

built from master:

>~/src/flatbuffers/grpc/samples/greeter$ ../../../build/flatc --grpc --rust greeter.fbs
../../../build/flatc: warning: GRPC interface generator not implemented for Rust

I know Rust support is new so I wasn't expecting this right away but it would be cool. I use grpc-rs so I was looking for support for that crate but others use grpc-rust.

[rw]

What is involved in implementing this?

[aardappel]

Would be worth looking at past gRPC / FlatBuffers language PRs, but it seems that every language is supported a bit differently in gRPC, so hard to say.

[stale[bot]]

This issue has been automatically marked as stale because it has not had activity for 1 year. It will be automatically closed if no further activity occurs. To keep it open, simply post a new comment. Maintainers will re-open on new activity. Thank you for your contributions.

[ufosky]

I found the grpc support has only c++ implementation, is this not suit for rpc?

[rw]

gRPC in a few languages supports FlatBuffers. Doing it for Rust is just a matter of creating a good design and implementing that. Any takers? :-]

[mcaveniathor]

I'm very interested in working on this -- would it be frowned upon to generate client and server stubs which are somewhat tied to an existing library and intended for use with its facilities? I really like of the modularity and performance that https://docs.rs/tonic/0.3.1/tonic/index.html[Tonic]

provides, as it builds on the tokio, bytes (all the better to make use of flatbuffers' zero-copy functionality!) and tower ecosystems, but I recognize that the dependencies it pulls in might be off-putting to some. Tonic's Codec trait is pretty flexible and seems well-suited for use with flatbuffers, so that gets my vote, but if the maintainers have a strong preference for one or the other I am happy to work on either implementation

[CasperN]

Imo, having some support is better than none, so we might as well start there. I expect the ecosystem to continue evolving and we'd need to adapt to those changes, so try not to tie everything to that particular stack too tightly

[ian-p-cooke]

note that i now use tonic as well, so i'm fine with supporting only that stack. once that's working i imagine you could look at grpc-rs, etc.

[github-actions[bot]]

This issue is stale because it has been open 6 months with no activity. Please comment or this will be closed in 14 days.

[CasperN]

bump, this is still cool

[katetsu]

I would be interested in contributing. anyone else willing to collaborate on the design plan? To get an idea, would this involve utilizing rust packages such as grpc-rs? or would this be too high-level and something based on mio is wished?

[CasperN]

I haven't worked with those libraries but my heuristic is that we should do whatever works for more users. I think this will mean using grpc-rs. Now, if we could implement something on mio that also led to grpc-rs support for free (or cheap), that would be even better

[frol]

Just FYI, I built a crate that integrates flatbuffers code-generation to cargo build process, so it is more convenient to use flatbuffers to develop applications: https://github.com/frol/flatc-rust. I'm not sure if it is of any use in this discussion, but I just wanted to mention it

[Ryanmtate]

Checking in on this; happy to help implement a rust generator for the compiler, seems like there are enough implementations to compare against. Let me know if anyone has already started on this or if anyone would like to sync up and get something implemented. Will try to put this on my road map for Q1 2022.

[CasperN]

@Ryanmtate yes please do! I'll be happy to help with code review!

[dbaileychess]

@Ryanmtate Are you still interesting in doing this?

[Ryanmtate]

Yes, I am still interested. A bit busy at the moment, but this would be a nice have for a work project I am working on.

I'll need to revisit in a month or so when I am have more time.

[github-actions[bot]]

This issue is stale because it has been open 6 months with no activity. Please comment or label not-stale, or this will be closed in 14 days.

[github-actions[bot]]

This issue was automatically closed due to no activity for 6 months plus the 14 day notice period.