跳到主要内容
本页尚未翻译

下面显示的是英文原文。

SQS bindings

With the asyncapi feature the generated document speaks SQS: the server, the queue behind each channel, and the topic of a fan-out position.

The core builds the AsyncAPI document from the app, before anything connects. This crate adds the specification's sqs binding, version 0.3.0, and with the sns feature its sns binding, version 1.0.0. A server reports where the service connects. A channel reports the queue behind it, whether the service reads it or publishes to it. A fan-out position's channel reports its topic.

Everything comes from the service's own declarations: the broker, the descriptors and the destinations the mount sites resolved. A setting the queue holds but the service did not name stays out, because reading it takes a connection. The document is published and shared, so no binding carries a credential. The binary #[ruststream::app] writes prints the document with asyncapi gen.

Example​

The dependency line:

ruststream-sqs-sns = { version = "0.7", features = ["asyncapi", "sns"] }

The service registers its broker under the label sqs, the key of its server in the document. cargo run --example sqs_asyncapi --features asyncapi,sns -- asyncapi gen prints the document.

fn service(broker: SqsBroker) -> impl App<State = ()> {
RustStream::new(AppInfo::new("orders", "1.0.0")).with_broker_labeled("sqs", broker, |b| {
b.include(confirm);
b.include(ship);
// The reply fans out from the topic its clause names.
b.include(settle).out_reply(SnsPublish::default());
})
}

#[ruststream::app]
fn app() -> impl App<State = ()> {
service(broker())
}