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]

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