Confusions with the Publish and Subscribe meaning/perspective

[fmvilas]

Description

I'm creating this issue to hold discussions about the problem with the publish/subscribe perspective. As it is right now, the perspective is from the "client". Let's put it a different way:

• A1 is the owner of one application.
• A2 is the owner of another application.
• If on the A1 AsyncAPI file it says publish, it means the A1 application allows or expects that A2 (and others) can publish messages to A1.
• If on the A1 AsyncAPI file it says subscribe, it means the A1 application allows or expects that A2 (and others) can subscribe to receive messages from A1.
• Same applies if you see an A2 AsyncAPI file.

Now, this is highly confusing especially for those working on private broker-based architectures. It's not for those working with public asynchronous APIs.

This is not an opinion. This is how it works right now. Switching the meaning of the verbs would not work either, as we saw in the past. Happy to listen for alternatives :)

Related issue(s)

• Add a View property to the info section to change the perspective of subscribe and publish operations. #390
• operationId usability in code generation #538
• Address perspective and channel reuse issues through introducing 'endpoint' concept #599
• ChannelItem.$ref field deprecation + proposal how to replace it with simpler and more flexible solution #607
• Proposal to solve publish/subscribe confusion #618

[jonaslagoni]

To me it is not so much about private broker-based architectures (since you might not have a broker) but rather those who use AsyncAPI to define the behavior of the specific application. i.e. you want to define what resources A1 provides to / consumes from others not what others may provide to / consume from A1.

[GeraldLoeffler]

(Paraphrasing from #390 (comment):)
The AsyncAPI document for A1 should use

• applicationSent when A1 sends messages to a channel (to which A2 might be subscribed)
• applicationReceived when A1 receives messages from a channel (to which A2 might publish).

This means that the AsyncAPI document for A2 (which is equally valid!) should use

• applicationReceived when A2 receives messages from a channel (such as those that were sent by A1)
• applicationSent when A2 sends messages to a channel (such as those to be received by A1)

[GeraldLoeffler]

i've submitted PR #521 that adds wording to the current spec simply to clarify the current meaning of publish and subscribe.

[nictownsend]

Continuing with thread in #390 - I do like the idea of splitting channels away from operations.

The ability to define what a channel looks like, then applications state the operations they perform on a channel.

However, it means either applications state the payload as part of their operation (which could lead to many discrepancies across spec files) - or the channel states its single payload/allOf (but different applications/operations can't have differing payloads). Which I'm guessing for NATS (request/reply) becomes a bigger problem.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴
It will be closed in 60 days if no further activity occurs. To unstale this issue, add a comment with detailed explanation.
Thank you for your contributions ❤️

[derberg]

This issue is related to #538 as well

[fmvilas]

Added #538 to the issue description to track them together.

[fmvilas]

Added #599 to the issue description.

[fmvilas]

Added a new proposal to the issue description: #618

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️

[dret]

Is this one still active? I went through 2.4.0 right now and still couldn't quite figure out what these word mean. The one-sentence descriptions given in https://www.asyncapi.com/docs/specifications/v2.4.0#channelsObject are not explaining the semantics and there doesn't seem to be a place in the spec that does? Maybe this has caused sufficient confusion to warrant a section in https://www.asyncapi.com/docs/specifications/v2.4.0#definitions?

[jonaslagoni]

@dret it is yes. Would be good to explain the semantics better for v2, do you want to champion this change?

For version 3, those confusions should be completely gone. See #618

[dret]

On 2022-05-16 14:01, Jonas Lagoni wrote: @dret <https://github.com/dret> it is yes. Would be good to explain the semantics better for v2, do you want to help clarify this?

i can give it a try. what's the best process?

For version 3, those confusions should be completely gone. See #618 <#618>

that's very good to see!

[jonaslagoni]

i can give it a try. what's the best process?

Awesome 👍

There is no one way, but I would suggest having something concrete suggestion to discuss around, so creating a PR that applies the changes you see as being a better description 🙂 You can do that by editing the markdown file of the AsyncAPI specification.

Not sure if it needs to wait until the next spec version up to the code owners @dalelane @fmvilas @derberg, otherwise we just retarget your PR so it will be included in the next version 🙂

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️