docs: introducing request/reply #2071
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jonaslagoni
requested review from
quetzalliwrites and
asyncapi-bot-eve
as code owners
✅ Deploy Preview for shimmering-choux-eb0798 ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
jonaslagoni
changed the title
Closed
|
quetzalliwrites
changed the title
quetzalliwrites
added
📑 docs
area/docs
quetzalliwrites
requested changes
Aug 17, 2023
smoya
reviewed
Aug 17, 2023
smoya
reviewed
Aug 17, 2023
smoya
reviewed
Aug 17, 2023
Co-authored-by: Alejandra Quetzalli <alejandra.olvera.novack@gmail.com>
Co-authored-by: Alejandra Quetzalli <alejandra.olvera.novack@gmail.com> Co-authored-by: Sergio Moya <1083296+smoya@users.noreply.github.com>
@alequetzalli Hmm, I kinda disagree with you here, cause it is getting started with request/reply in a similar fashion as https://www.asyncapi.com/docs/tutorials/getting-started/asyncapi-documents is. Concept does not make much sense as this is ONLY related to how you do it AsyncAPI and not explaining the underlying concept of how request/reply works 🤔 Guide could be yea, we just don't have anything yet that details how to use specific features in AsyncAPI documents, so it might seem misplaced a bit 🤔 But you have a better overview of the docs and what needs to be where, so just let me know where I should move it to and I will do it 👍 |
AnimeshKumar923
suggested changes
Aug 28, 2023
There was a problem hiding this comment.
- I have reviewed this from my end.
- Had some difficulties and have pinged Alejandra and Fran for the same.
- Please provide your feedback. 🙏 @alequetzalli @fmvilas
|
|
||
| ## Multiple messages over the same channel with request/reply | ||
|
|
||
| In WebSocket, you often encounter that a channel will contain multiple messages, which means you will have to make your operations explicitly define which messages are used for each operation. |
There was a problem hiding this comment.
Suggested change
| In WebSocket, you often encounter that a channel will contain multiple messages, which means you will have to make your operations explicitly define which messages are used for each operation. | |
| In WebSocket, you often encounter that a channel will contain multiple messages, which means you will have to explicitly define your operations and which messages are used for each operation. |
I'm having difficulty re-wording this. Please take a look @alequetzalli @fmvilas
Co-authored-by: Animesh Kumar <kumaranimesh923@gmail.com>
jonaslagoni
requested review from
GreenRover,
smoya,
quetzalliwrites and
AnimeshKumar923
kakabisht
reviewed
Sep 2, 2023
| weight: 20 | ||
| --- | ||
|
|
||
| A quite common messaging pattern is [request-reply](https://www.enterpriseintegrationpatterns.com/patterns/messaging/RequestReply.html). It describes a **requester**, which sends a request message and waits for a reply - and a **replier** which receives the request and responds with a reply. |
There was a problem hiding this comment.
Suggested change
| A quite common messaging pattern is [request-reply](https://www.enterpriseintegrationpatterns.com/patterns/messaging/RequestReply.html). It describes a **requester**, which sends a request message and waits for a reply - and a **replier** which receives the request and responds with a reply. | |
| A quite common messaging pattern is [request-reply](https://www.enterpriseintegrationpatterns.com/patterns/messaging/RequestReply.html). It describes a **requester**, which sends a request message and waits for a reply - and a **replier**, which receives the request and responds with a reply. |
kakabisht
reviewed
Sep 2, 2023
|
|
||
| ## Describing a requester | ||
|
|
||
| We are going to use a very simple ping and pong example where a requester sends the ping and the responder responds with a pong. To describe a **requester** in AsyncAPI, we make use of an operation that `send`s to the `ping` channel and expects a `reply` over `pong`. |
There was a problem hiding this comment.
Suggested change
| We are going to use a very simple ping and pong example where a requester sends the ping and the responder responds with a pong. To describe a **requester** in AsyncAPI, we make use of an operation that `send`s to the `ping` channel and expects a `reply` over `pong`. | |
| We are going to use a very simple ping and pong example where a requester sends the ping, and the responder responds with a pong. To describe a **requester** in AsyncAPI, we make use of an operation that `send`s to the `ping` channel and expects a `reply` over `pong`. |
kakabisht
reviewed
Sep 2, 2023
| $ref: '#/channels/pong' | ||
| ``` | ||
|
|
||
| The `reply` section defines all the necessary information to properly reply to the request, such as where to, and with what message. This is just a simple example, but you can check the full list of properties under the [Operation Reply Object](https://www.asyncapi.com/docs/reference/specification/latest#operationReplyObject) |
There was a problem hiding this comment.
Suggested change
| The `reply` section defines all the necessary information to properly reply to the request, such as where to, and with what message. This is just a simple example, but you can check the full list of properties under the [Operation Reply Object](https://www.asyncapi.com/docs/reference/specification/latest#operationReplyObject) | |
| The `reply` section defines all the necessary information to properly reply to the request, such as where to and with what message. This is just a simple example, but you can check the full list of properties under the [Operation Reply Object.](https://www.asyncapi.com/docs/reference/specification/latest#operationReplyObject) |
kakabisht
reviewed
Sep 2, 2023
|
|
||
| In the simple example above, we saw how you could set up a request/reply pattern across two applications where one application is the requester and the other is the replier. | ||
|
|
||
| However, in an protocol-agnostic world there are many different sub-patterns to the simple request/reply. All of which AsyncAPI v3 enables. |
There was a problem hiding this comment.
Suggested change
| However, in an protocol-agnostic world there are many different sub-patterns to the simple request/reply. All of which AsyncAPI v3 enables. | |
| However, in a protocol-agnostic world there are many different sub-patterns to the simple request/reply. All of which AsyncAPI v3 enables. |
kakabisht
reviewed
Sep 2, 2023
|
|
||
| The request/reply can also occur over the same channel (for example `/`), which could be HTTP or WebSocket. | ||
|
|
||
| To do this it's as simple as having both channels use the same address. |
There was a problem hiding this comment.
Suggested change
| To do this it's as simple as having both channels use the same address. | |
| To do this, it's as simple as having both channels use the same address. |
|
|
||
| In some cases, we do not know the reply channel at design time, but instead, it's dynamically determined at runtime. This could, for example, be using the request message payload or header to dictate the response address. | ||
|
|
||
| Take notice of how we utilize `address: null` to define that we don't know the address just yet. This is just for illustration purposes as you can also omit the property entirely. We then utilize the [Operation Reply Address Object](https://www.asyncapi.com/docs/reference/specification/latest#operationReplyAddressObject) to define that the address of where to send the reply is located dynamically in the message header under `replyTo`. |
There was a problem hiding this comment.
Suggested change
| Take notice of how we utilize `address: null` to define that we don't know the address just yet. This is just for illustration purposes as you can also omit the property entirely. We then utilize the [Operation Reply Address Object](https://www.asyncapi.com/docs/reference/specification/latest#operationReplyAddressObject) to define that the address of where to send the reply is located dynamically in the message header under `replyTo`. | |
| Take notice of how we utilize `address: null` to define that we don't know the address just yet. This is just for illustration purposes, but you can also omit the property entirely. We then utilize the [Operation Reply Address Object](https://www.asyncapi.com/docs/reference/specification/latest#operationReplyAddressObject) to define that the address of 'where to send the reply' is located dynamically in the message header under `replyTo`. |
- Is this format appropriate? I think the
where to send the replycan be wrapped in some quotations or some sort of re-wording can be done but I'm not sure how to approach it. - Requesting your assistance @alequetzalli
|
|
||
| In WebSocket, you often encounter that a channel will contain multiple messages, which means you will have to make your operations explicitly define which messages are used for each operation. | ||
|
|
||
| The following example is very similar to the above example, with the difference being that we merged the two ping and pong channels into a single one (because they use the same address). The request operation then explicitly defined the request message among the available channel messages and the same for the reply. |
There was a problem hiding this comment.
Suggested change
| The following example is very similar to the above example, with the difference being that we merged the two ping and pong channels into a single one (because they use the same address). The request operation then explicitly defined the request message among the available channel messages and the same for the reply. | |
| The following example is very similar to the above example, with the difference being that we merged the two ping and pong channels into a single one (because they use the same address). The request operation then explicitly defines the request message among the available channel messages and the same for the reply. |
defined or defines? @alequetzalli
GreenRover
reviewed
Sep 7, 2023
|
|
||
| ## Request/reply with dynamic response channel | ||
|
|
||
| In some cases, we do not know the reply channel at design time, but instead, it's dynamically determined at runtime. This could, for example, be using the request message payload or header to dictate the response address. |
There was a problem hiding this comment.
May be mention that this pattern is mostly used when:
You have multiple possible requestor ant want archive that you only receive responses your requested.
With an static response address all possible requestor will receive the responses from every one and need to filter by correlation id, if the received response is one that match a question of your self.
There was a problem hiding this comment.
Hint there are even 2 sub types.
Type 1: The process defines an inbox on process startup to receive only responses where it self didt the request for. But also need an correlationId to assign the response to the correct Programm thread. Assuming that the application is not single threaded and blocking.
Type 2: The inbox will be created dedicated for each requests. Than there is no need for an correlationId.
|
There are plans to rewrite the entire thing into something different by Rohit and @alequetzalli, so I am closing the PR and releasing the content (almost) as is, on my own website so it's not goes to waste and creates a bit of hype 🙂 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This PR adds a page introducing request/reply concept with AsyncAPI
Related issue(s)
Related to #1434