Crates.io | protobuf-zmq-rust-generator |
lib.rs | protobuf-zmq-rust-generator |
version | 0.1.1 |
source | src |
created_at | 2024-01-30 14:01:11.728768 |
updated_at | 2024-02-07 20:18:57.479087 |
description | A prost/protobuf service generator for rust that generates a zmq server |
homepage | |
repository | https://github.com/usherlabs/protobuf-zmq-rust-generator |
max_upload_size | |
id | 1120255 |
size | 28,771 |
This crate works with prost
to develop a service generator for
a ZeroMQ + Protobuf implementation, aiding in efficient data
transmission between processes via sockets. It supports both the pub-sub and request-reply patterns.
Originally designed to facilitate communication between a NodeJS client and a Rust server, this package can be adapted to any language that adheres to this protocol.
build-dependency
in your Cargo.toml
file.build.rs
file in your project's root. Look
to prost-build documentation for detailed instructions. prost_build::Config::new()
// Optional: defaults to $OUT, can be changed for autocomplete support
.out_dir(out_dir)
.service_generator(Box::new(ZmqServerGenerator {})) // here
.compile_protos(& ["your_proto_file.proto"], & ["your/proto/location/"])
your_proto_file.rs
in the out_dir
, containing the generated code.Now to operate a service server:
[Method]Handler
trait and implement it for responses.publish
method for each pubsub
method in your .proto
file.Check our test files for comprehensive examples.
In this section, we will discuss the design decisions that went into this package. It's not necessary to understand every detail to use this package, but it may be helpful to understand its limitations.
Given these, we have 2 patterns in operation:
[methodName, Output]
, in bytes
message EmptyInput {}
message SubscriptionItem {
string data = 1;
}
service MyServerService {
rpc SubscribeToItems(EmptyInput) returns (stream SubscriptionItem) {}
}
The data transferred should be ["SubscribeToItems", SubscriptionItem]
.
methodName
message..proto
file defined return type should be a data stream.[requestId, BLANK, methodName, Input]
, in bytes. The server should reply
with [clientId, requestId, Output]
message MyRequestInput {
int32 time_to_sleep = 1;
}
message MyRequestResult {
bool all_ok = 1;
string message = 2;
}
service MyServerService {
rpc MyRequestMethod(MyRequestInput) returns (MyRequestResult) {}
}
The transferred data for this example should be [requestId, BLANK, "MyRequestMethod", MyRequestInput]
.
requestId
is a randomly generated string by the clientBLANK
is an empty frame, used to mimic the original protocol for REQUEST/REPLY patterns.clientId
is included by default by clients. ROUTER should also include this in the reply to ensure the correct
dispatching of the reply to a client.It's possible to use both patterns on the same service: Note: Currently, we only support building Server implementations with this package. Future updates may include client implementations.
We welcome contributions to this project!