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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add option to disable rendering service level tags #2917

Closed
kkolur opened this issue Oct 1, 2022 · 7 comments
Closed

Add option to disable rendering service level tags #2917

kkolur opened this issue Oct 1, 2022 · 7 comments

Comments

@kkolur
Copy link
Contributor

kkolur commented Oct 1, 2022

馃殌 Feature

here it looks like tags at the root level are still TODO. Is this planned to be prioritized?Right now, in the output, the tags are automatically generated with the service(s) names but I would prefer to override that behavior by defining my own set of tags at the root level. OR, we can make the rendering of service tags optional and defaulted to true through command line flags?

Also, according to OpenAPI docs, extensions are supported for tags as well. Could we add this as well?

How difficult would this be overall?

@johanbrandhorst
Copy link
Collaborator

There are a few settings already for how the tags are generated I believe:

openAPINamingStrategy = flag.String("openapi_naming_strategy", "", "use the given OpenAPI naming strategy. Allowed values are `legacy`, `fqn`, `simple`. If unset, either `legacy` or `fqn` are selected, depending on the value of the `fqn_for_openapi_name` flag")
. I'm not sure exactly what you're asking for. Do you want the ability add tags? How do you want to map those tags to objects? What do you want to do with extensions in tags? I think the use case has to be compelling enough that I could see it being useful to many of our users. Notably, you are the first to ask for this, which is not a great indicator of the need.

@kkolur
Copy link
Contributor Author

kkolur commented Oct 4, 2022

@johanbrandhorst I want the option to not automatically render service tags. RIght now the service tags are automatically generated here. If we could have some sort of command line flag that could let us disable that is what I was asking for.

Using ReDoc, after we added tags to each endpoint, the service level tags were still displayed in the left hand side nav bar which we dont want to display for the users of the docs. We could write a post process script that removes the root level tags object, but I figured it wouldn't hurt if we added a cli flag thats defaulted to true but have the option to set it to false

@johanbrandhorst
Copy link
Collaborator

I see, thanks for clarifying. I could see a flag that disables tags altogether, but I'm not convinced the need is good enough yet. Maybe we can leave this issue open and see if there are more users who want this functionality before we decide to add it?

@johanbrandhorst johanbrandhorst changed the title Implement tags at root level and allow tags to have extensions Add option to disable rendering if service tags Oct 4, 2022
@kkolur kkolur changed the title Add option to disable rendering if service tags Add option to disable rendering service level tags Oct 5, 2022
@kkolur
Copy link
Contributor Author

kkolur commented Oct 5, 2022

@johanbrandhorst I wouldn't want to disable tags altogether, I just would want an option to disable the rendering of service tags. I think such an option thats defaulted to true wouldn't hurt too much and would only serve as an extra layer of customization that we already have available through the cli flags 馃槂

Thoughts?

@davix
Copy link

davix commented Oct 10, 2022

We have the same requirement. (asked in slack before https://gophers.slack.com/archives/CBATURP1D/p1653487121966699)
We use the swagger at API gateway which exposes a few backend grpc services. Because backend services' name are inappropriate to be exposed, we define custom tags for the APIs with different grouping strategy. But the service tags still exist now.
May contribute if there are guidance.

@kkolur
Copy link
Contributor Author

kkolur commented Oct 10, 2022

I think I have a decent idea of what to do while perusing the codebase so I can take the task on as well @davix 馃檪

@kkolur
Copy link
Contributor Author

kkolur commented Oct 11, 2022

@johanbrandhorst PR here 馃槉

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

No branches or pull requests

3 participants