| Crates.io | rotors |
| lib.rs | rotors |
| version | 0.2.0 |
| created_at | 2023-09-01 15:55:55.350309+00 |
| updated_at | 2023-09-27 12:58:31.630192+00 |
| description | tonic-based RPC library |
| homepage | https://github.com/hypermynds/rotors |
| repository | https://github.com/hypermynds/rotors |
| max_upload_size | |
| id | 961017 |
| size | 6,187 |
Rust PROTOcols without the Pain
You probably shouldn't, because this library is under development and has not gone through serious scrutiny yet.
However, if you would like an easier way to use native Rust types inside a
tonic project, this might be useful to you.
Instead of writing a gRPC xyz.proto file and using the tonic-build tools in your build.rs,
you can just use a simple macro in your code, and let the macro do most of the heavy lifting!
use rotors::rotors;
use serde::{Deserialize, Serialize};
#[derive(Clone, Debug, Deserialize, Serialize)]
pub struct HelloRequest {
pub name: String,
}
#[derive(Clone, Debug, Deserialize, Serialize)]
pub struct HelloReply {
pub message: String,
}
rotors! {
package helloworld;
service Greeter {
rpc SayHello (super::HelloRequest) returns (super::HelloReply);
}
}
The rotors!() macro will define two new rust modules, containing the tonic client
and server structures. From there onwards, everything will be just like
the tonic you are used to, except that you are finally free to write your
own enums without the tedious boilerplate required by gRPC.
When using rotors you are creating some RPC code that is now NOT COMPATIBLE
with gRPC. If this is fine for you, then go for it!
On the other hand, if you are writing a big project, or want to communicate between instances running different versions of your software, or even sofware written in different languages, this crate won't be of much use to you.