Add "channelContext" property to server object

[195858]

The suggestion is to add a channelContext property to the "Server Object".

The motivation is the following use case: Organisation has a number of logical stages that artifacts are propagated through.

• Dev
• QA
• UA
• Staging
• Prod

However the physical infrastructure consists of shared brokers for Dev, QA, UA. This means we need to have a dedicated root namespace for each environment on this shared infrastructure ...

Consider the channel is called smartylighting/streetlights/1/0/event/{streetlightId}/lighting/measured - in the shared environment the actual topics that is supposed to be used must be prefixed e.g. dev/smartylighting/streetlights/1/0/event/{streetlightId}/lighting/measured We need to be able to describe the actual topics in the Async API spec without changing the channel description.

The logical place to put it seems to be the "Server Object" so clients can easily switch between environments without changes to the channel definitions. Here's an example of how it could look like:

servers:
  qa:
    url: mqtt://xxxyyyzzz.messaging.solace.cloud:1833
    channelContext: qa
    protocol: mqtt
    description: Solace broker

Code generators or the generated code can prepend the channelContext to all channels and a developer can switch between environments easily by using a different server endpoint.

[derberg]

@195858 sounds to me like you want to bring back the feature that was in the spec in 1.2 version -> https://github.com/asyncapi/spec/tree/1.2.0#baseTopicString

am I right? @fmvilas do you recall why it was removed in 2.0?

[fmvilas]

I was considering moving it to the Server object —as @195858 is proposing— but it was going to add complexity and decided to leave it out. No special reason other than "too much for a single guy to handle" 😄

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity :sleeping: 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 :heart:

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity :sleeping: 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 :heart:

[derberg]

@195858 do you plan to champion this proposal further ?

[195858]

I'd really like to have an optional "channelContext" - so what do I need to do to "champion" this issue?

[jonaslagoni]

@195858 pinging @derberg again as it probably went under the radar.

You can take a look at the contributing guideline, as it describes the process of champion the issue through 🙂 Let us know if you have any further questions about how to achieve it 👍

[derberg]

Yeah, what I can tell you is:

• that we definitely need some full example?
• real-life use case
• explain how you deal with it now
• did you try with extensions first?
• are there other ways to solve it using existing features, did you try channel parameters? what about path in the URL of the server
• your use case sounds like something others (other users) might already face, did you try to check with others how are they dealing with such a use case, or maybe they need it too?

so yeah, championing is making sure the proposal is fully described, with all details, covering other use cases, and involves other users in the discussion to see their perspective. All to make sure we are not solving a single problem of a single company with a new spec feature

[jonaslagoni]

@195858 do you want to champion this? 🙂 Or can we consider this issue as needs champion? 🤔

[smoya]

@195858 Do you wanna take the lead on this and champion it? We do have a new release in a month so we could include it on it if the proposal reaches the proper stage.

[github-actions[bot]]

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

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 :heart:

[derberg]

@smoya isn't it the same as tag property that you are now pushing for 2.5?

[smoya]

https://github.com/asyncapi/spec/tree/1.2.0#baseTopicString

It is a combination of https://github.com/asyncapi/spec/issues/654 but with the fact channels could use those values for prefixing their addresses.

A similar feature would be to add a Parameter to the channel but get the enum from the Server tags. A bit tricky tbh.

[github-actions[bot]]

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

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 :heart: