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

[Discuss] SavedObjects.incrementCounter in the UI? #88497

Closed
afharo opened this issue Jan 15, 2021 · 6 comments
Closed

[Discuss] SavedObjects.incrementCounter in the UI? #88497

afharo opened this issue Jan 15, 2021 · 6 comments
Labels
discuss Feature:Saved Objects Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc

Comments

@afharo
Copy link
Member

afharo commented Jan 15, 2021

Would it make sense to add the incrementCounter API to the public contract?

It could help plugins needing to maintain a counter in the UI (i.e.: for telemetry purposes), instead of creating an HTTP API and run the method on the server end.

What do you think?

@afharo afharo added discuss Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc Feature:Saved Objects labels Jan 15, 2021
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-core (Team:Core)

@afharo afharo changed the title [Discuss] SavedObjects.incrementCounter in the UI? [Discuss] SavedObjects.incrementCounter in the UI? Jan 15, 2021
@pgayvallet
Copy link
Contributor

FWIW, even on the server-side, incrementCounter is not exposed on SavedObjectsClient, and is only available when directly working with a SavedObjectsRepository. Exposing this API on the client-side client means exposing it on its server-side counterpart too (not that this is necessarily an issue).

I'm not really sure what was the idea behind the decision of not exposing this API on the server-side client in the first place, but I feel like incrementCounter was more or less considered as a private/protected API? Does anyone have more context on that?

Also @afharo what specific usages of this API from the client-side do you foresee?

@rudolf
Copy link
Contributor

rudolf commented Jan 19, 2021

incrementCounter uses scripting. For 7.x having scripts enabled on Elasticsearch is not a requirement. Although many features rely on it, the intention has been to have most features continue to work without scripting (it's possible that Kibana is anyway completely broken when scripting is disabled we just don't know it, but AFAIK that was the thinking behind this when this API was introduced ~2+ years ago)

@pgayvallet
Copy link
Contributor

it's possible that Kibana is anyway completely broken when scripting is disabled we just don't know it

AFAIK it probably is 🙈

@rudolf
Copy link
Contributor

rudolf commented Jan 19, 2021

Although even if we decide that this API is "safe" to use outside of telemetry, I would not want to expose it on public because of the discussion in #84729 (comment) Although we still need to flesh out a more detailed roadmap for working towards that goal, I think it makes sense to not introduce any new API's on the public SavedObjectsClient but instead only expose it on the server SavedObjectsClient and encourage plugins to create HTTP API's that capture their business domain.

@afharo
Copy link
Member Author

afharo commented Jan 19, 2021

Makes sense to me! Thank you both for explaining! FWIW, I'm happy to close this issue.

@afharo afharo closed this as completed Jan 19, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discuss Feature:Saved Objects Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc
Projects
None yet
Development

No branches or pull requests

4 participants