The CLI¶
The ruststream command-line tool drives cargo with the framework's subcommands. Scaffolding a
new project is cargo generate (see Scaffolding below), so the tool no longer ships
its own new command.
A RustStream service is an ordinary Rust binary whose main is generated by #[ruststream::app].
The CLI does not introspect it; run and asyncapi gen shell out to cargo run against the target
crate.
Commands¶
ruststream run # cargo run -- run, against ./Cargo.toml
ruststream run -p ./my-service # against another crate
ruststream run --release # release build
ruststream asyncapi gen # print the AsyncAPI document
ruststream asyncapi gen -o spec.json # write it to a file
ruststream asyncapi gen --yaml # YAML instead of JSON
run and asyncapi gen take -p/--manifest-path (defaulting to the current directory) to point at
a crate other than the working directory.
The generated entry point¶
#[ruststream::app] turns a builder function into a main that understands run and
asyncapi gen, so there is no runtime boilerplate:
use ruststream::memory::MemoryBroker;
use ruststream::runtime::{AppInfo, RustStream};
#[ruststream::app]
fn app() -> RustStream {
RustStream::new(AppInfo::new("orders", "0.1.0"))
.with_broker(MemoryBroker::new(), |b| b.include(handle))
}
Because the dispatch lives in the generated binary, both ruststream run and a plain
cargo run -- run start the service the same way. ruststream run is a convenience that finds the
crate and forwards the command to cargo.
Scaffolding¶
New projects are generated with cargo generate
from a template, not by this tool; the command and the project it writes are in the
quick start. Templates are owned by the crate whose broker they
wire: the in-memory starter lives in this repo, and each broker repo ships its own, typically one
per transport or topology (for example nats vs nats-js). Authoring a template for a new broker
follows the template contract.