From 6231f8a10b24dc54d1fdc1387f25e2dd6f0c7f41 Mon Sep 17 00:00:00 2001 From: Taylor Thomas Date: Mon, 26 Feb 2024 16:07:37 -0700 Subject: [PATCH] feat(*): Updates messaging to support request-reply This makes several updates to the messaging interface. Initially the README said that this wasn't going to support request/reply, but based on my reading of the Kafka, NATS, MQTT, and SQS APIs, this is a fairly common pattern. Another piece of evidence here is what I've seen as a wasmCloud maintainer from our users. Request/reply is one of the more common things we see with a messaging service. Please note that this doesn't _require_ the use of a reply-to topic, just exposes it for use. I also did a few other changes here. First is that I added the topic to the message. This was common across all systems and is often used by code to select the appropriate logic to perform. I also removed the format field as this didn't seem to be a common parameter across various services. We could definitely add a content-type member to this record in the future if needed, but I think much of that can be passed via the metadata field. There are other things I might suggest some changes to, but I want to think on them some more and open some issues to discuss them first Signed-off-by: Taylor Thomas --- README.md | 2 +- wit/producer.wit | 2 ++ wit/types.wit | 21 +++++++-------------- 3 files changed, 10 insertions(+), 15 deletions(-) diff --git a/README.md b/README.md index 414f56c..d3f2d7c 100644 --- a/README.md +++ b/README.md @@ -45,7 +45,7 @@ Overall, the messaging interfaces aim to make it easier to build complex and sca ### Non-goals - The messaging service interfaces do not aim to provide advanced features of message brokers, such as broker clustering, message persistence, or guaranteed message delivery. These are implementation-specific details that are not addressed by the interfaces. -- The messaging service interfaces do not aim to provide support for every possible messaging pattern or use case. Instead, they focus on the common use cases of pub-sub and push-based message delivery. Other messaging patterns, such as request-reply or publish-confirm-subscribe, are outside the scope of the interfaces. +- The messaging service interfaces do not aim to provide support for every possible messaging pattern or use case. Instead, they focus on the common use cases of pub-sub, push-based message delivery, and request-reply. Other messaging patterns, such as publish-confirm-subscribe, are outside the scope of the interfaces. - The messaging service interfaces do not aim to provide a specific implementation of a message broker. Instead, they provide a standard way to interact with any message broker that supports the interfaces. ### API walk-through diff --git a/wit/producer.wit b/wit/producer.wit index fa795d8..8c08156 100644 --- a/wit/producer.wit +++ b/wit/producer.wit @@ -1,5 +1,7 @@ interface producer { use messaging-types.{client, channel, message, error}; + /// Sends a message to the given channel/topic. This topic can be overridden if a message has a + /// non-empty topic field send: func(c: client, ch: channel, m: list) -> result<_, error>; } diff --git a/wit/types.wit b/wit/types.wit index b7c9803..81e2e29 100644 --- a/wit/types.wit +++ b/wit/types.wit @@ -23,22 +23,15 @@ interface messaging-types { extensions: option>> } - /// Format specification for messages - /// - more info: https://github.com/clemensv/spec/blob/registry-extensions/registry/spec.md#message-formats - /// - message metadata can further decorate w/ things like format version, and so on. - enum format-spec { - cloudevents, - http, - amqp, - mqtt, - kafka, - raw - } - - /// A message with a binary payload, a format specification, and decorative metadata. + /// A message with a binary payload and additional information record message { + /// The topic or subject this message was received or should be sent on + topic: string, + /// An optional topic for use in request/response scenarios + reply-to: option, + /// An opaque blob of data data: list, - format: format-spec, + /// Optional metadata (also called headers or attributes in some systems) attached to the message metadata: option>> } } \ No newline at end of file