Crates.io | rotors |
lib.rs | rotors |
version | 0.2.0 |
source | src |
created_at | 2023-09-01 15:55:55.350309 |
updated_at | 2023-09-27 12:58:31.630192 |
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 PROTO
cols without the P
ain
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 enum
s 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.