Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: remove the reply filed support in operations #680

Merged
merged 6 commits into from
Jan 11, 2024

Conversation

KhudaDad414
Copy link
Member

@KhudaDad414 KhudaDad414 commented Jan 9, 2024

This PR removes the request/reply pattern support from Glee.

Reason for Removal: Glee uses bindings for its protocols, but the current spec allows replies to different channels, complicating the required bindings for request/reply support in Glee's version 3.

Why Remove Reply Support Entirely?: To avoid confusion, we're removing the reply feature until AsyncAPI spec issue #1009 is resolved, as 'reply' has different meanings in the spec and Glee framework.

Copy link

sonarcloud bot commented Jan 10, 2024

Quality Gate Passed Quality Gate passed

Kudos, no new issues were introduced!

0 New issues
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud

@KhudaDad414 KhudaDad414 marked this pull request as ready for review January 10, 2024 13:40
@@ -37,7 +39,7 @@ export default async function (event) {
|Attribute|Type|Description|
|---|---|---|
|send|array<[OutboundMessage](#anatomy-of-an-outbound-message)>|A list of outbound messages to send when the processing of the inbound event has finished. All clients subscribed to the given channel/topic will receive the message.
|reply|array<[OutboundMessage](#anatomy-of-an-outbound-message)>|A list of outbound messages to send as a reply when the processing of the inbound event has finished. This is useful when the target of your message is the sender of the inbound event. Note, however, that this only works when you're running Glee as a server. For example, using `reply` when receiving a WebSocket message is fine and the reply will exclusively go to the client that sent the message. However, if you're receiving a message from an MQTT broker, `reply` will work exactly the same way as `send` above, and will send the message to all the clients subscribed to the given channel/topic.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

interesting, reply is no more. it turned out to be obsolete. thanks for the update

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it was cool to have it, you didn't have to specify the channel and the server that you sent the message to. but I think it's a source of confusion for now that we release version 1.0. this is something that we need for v2 of glee.

Copy link
Member

@Souvikns Souvikns left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 🎉 . I will update the rest of the examples

@KhudaDad414
Copy link
Member Author

/rtm

@asyncapi-bot asyncapi-bot merged commit bf65565 into asyncapi:master Jan 11, 2024
20 checks passed
@asyncapi-bot
Copy link
Contributor

🎉 This PR is included in version 0.34.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants