feat: add tags field to Server Object

[smoya]

Description

This PR adds support for defining Tags at Server Object. They can be used for providing metadata, including the environment such as production, development, etc.

Related issue(s)
Fixes #654
Fixes #465

[fmvilas]

Let's avoid using API and documentation. These are just specific use cases IMHO. What about this:

Suggested change

	<a name="serverObjectTags"></a>tags | [Tags Object](#tagsObject) | A list of tags for API documentation control. Tags can be used for logical grouping of servers.
	<a name="serverObjectTags"></a>tags | [Tags Object](#tagsObject) | A list of tags for logical grouping and categorization of servers.

[smoya]

Shall we apply this change to Operation, OperationTrait, Message, and MessageTrait as well? I.e. https://github.com/asyncapi/spec/blob/master/spec/asyncapi.md?plain=1#L712

[fmvilas]

That would be awesome yes 👍

[smoya]

Okey changes applied.

However, cc @alequetzalli in case you want to take this opportunity to add, remove, fix, and or rephrase this description.

[derberg]

I would be good to extend some of the official examples, like streetlights for kafka with this feature, as this use case is most common, that Kafka has multiple production servers. Could make sense to also add example description in Tags object.

separate question:
I think we need to mention at least in this PR that we are aware there is a feature that allows you too specify that some channel is available only on a given server (CHANNEL_NAME.servers).

I somehow feel that people will immediately assume, they can refer not only to a server by server name but the tag too 😄

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[smoya]

I would be good to extend some of the official examples, like streetlights for kafka with this feature, as this use case is most common, that Kafka has multiple production servers.

I don't fully get what you mean by Kafka has multiple production servers. Would you mind sharing an example or clarifying it? 🙏

Could make sense to also add example description in Tags object.

Good suggestion! I've pushed a new commit with the requested change.

separate question: I think we need to mention at least in this PR that we are aware there is a feature that allows you too specify that some channel is available only on a given server (CHANNEL_NAME.servers).

I somehow feel that people will immediately assume, they can refer not only to a server by server name but the tag too 😄

TBH I don't see the relation between CHANNEL_NAME.servers and the tags. Those are not selectors nor similar.

[derberg]

I don't fully get what you mean by Kafka has multiple production servers. Would you mind sharing an example or clarifying it? 🙏

so with Kafka you can have a cluster of brokers. Related discussion #465

I'm pretty sure people will use tag to address above.

TBH I don't see the relation between CHANNEL_NAME.servers and the tags. Those are not selectors nor similar.

Am I really the only one (with Kafka cluster use case in mind) that thinks that people will like to do CHANNEL_NAME.servers=['env:production'] 😄

[fmvilas]

Am I really the only one (with Kafka cluster use case in mind) that thinks that people will like to do CHANNEL_NAME.servers=['env:production'] 😄

This is a really good point 🤔 Maybe something to consider for 3.0.0?

[smoya]

@fmvilas @dalelane @derberg a last review so we can include this into 2.5 finally?

[derberg]

is this PR resolving #654? I think yes, so please update description

do we agree that this PR also solves #465? 👀 @dalelane that wanted to champion the other proposal

---

@smoya 👇🏼 was not yet addressed

I would be good to extend some of the official examples, like streetlights for kafka with this feature, as this use case is most common, that Kafka has multiple production servers

and regarding 👇🏼

TBH I don't see the relation between CHANNEL_NAME.servers and the tags. Those are not selectors nor similar.

I think we have an agreement that for 3.0 we want to go $ref-everywhere direction, including CHANNEL_NAME.servers, so I guess we can just leave it as it is without any concerns.

[smoya]

@smoya 👇🏼 was not yet addressed

@derberg I updated the socialmedia, streetlights-kafka and streetlights-mqtt examples. Can you take a look to those? 🙏

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[derberg]

@dalelane can you have a final look please, ref -> #809 (comment)

[dalelane]

This looks really good - I like the examples, as they are super helpful prompts for the ways that tags can be used, instead of just mechanically showing how to add a tag 👍

[derberg]

@dalelane thanks, does it also solve #465 from your perspective?

[dalelane]

@dalelane thanks, does it also solve #465 from your perspective?

yeah I think so - I'll add a comment there, too

[derberg]

@smoya can you update the description accordingly so the other issue is also resolved after merge, by default?

and then merge 💪🏼

[derberg]

@magicmatatjahu something we might want to support in react component out of the box after release 😉

[smoya]

@smoya can you update the description accordingly so the other issue is also resolved after merge, by default?

and then merge 💪🏼

Done at the same time you posted this comment ⚡ 🏃

[magicmatatjahu]

@derberg I will remember :)

[char0n]

Looks all good here and ready for 2.5.0, going for a merge. Thanks @smoya!

[derberg]

[char0n]

/rtm

[asyncapi-bot]

🎉 This PR is included in version 2.5.0-next-spec.2 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀