-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
[Infrastructure UI] Implement Metrics explorer views CRUD endpoints #155621
[Infrastructure UI] Implement Metrics explorer views CRUD endpoints #155621
Conversation
🤖 GitHub commentsExpand to view the GitHub comments
Just comment with:
|
Pinging @elastic/infra-monitoring-ui (Team:Infra Monitoring UI) |
@crespocarlos as this is an implementation mirroring the one done for the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great job! The CRUD works as expected. Loved how simple and easy to understand the endpoints are.
I just left a few minor comments and I missed 2 possible additional test cases that could be nice to have.
@@ -0,0 +1,29 @@ | |||
/* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: This is similar to create_metrics_explorer_view.ts
. I'm wondering if we could have types like create_or_update_explorer_view.ts
types instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree they are the same, but since the request payloads don't strictly represent the same structure in future, I preferred to keep them split for isolated responsibilities.
}, | ||
async (_requestContext, request, response) => { | ||
const { body } = request; | ||
const { metricsExplorerViews } = (await getStartServices())[2]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: you can completely ignore this. For me, it's easier to understand this:
const [, , { metricsExplorerViews }] = await getStartServices();
}); | ||
}); | ||
|
||
describe('.update', () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I couldn't find a test here to validate PUT /api/infra/metrics_explorer_views/0
and DELETE /api/infra/metrics_explorer_views/0
to check the message when metrics explorer view with id is "0". Do you think it's worth it to have a test case for this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These tests don't validate that piece of logic because the gate for the accepted values is at the endpoint level, when the parameters are validated, it shouldn't even reach the client if the value is not acceptable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah. indeed.
public async find(query: MetricsExplorerViewRequestQuery): Promise<MetricsExplorerView[]> { | ||
this.logger.debug('Trying to load metrics explorer views ...'); | ||
|
||
const sourceId = query.sourceId ?? 'default'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
default
is repeated in the get
and update
functions. We could create a constant for this, wdyt?
|
||
if (defaultViewPosition !== -1) { | ||
const element = views.splice(defaultViewPosition, 1)[0]; | ||
views.unshift(element); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
suggestion: We could create a new array instead of mutating the views
array passed as a parameter.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would make sense for immutability purposes, but as we already modified the original instance with .splice
to remove the item, there shouldn't be any issue with this mutation.
I measure the performance impact and it's irrelevant in this case.
this.infraSources.getSourceConfiguration(this.savedObjectsClient, sourceId), | ||
this.savedObjectsClient.find({ | ||
type: metricsExplorerViewSavedObjectName, | ||
perPage: 1000, // Fetch 1 page by default with a max of 1000 results |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
suggestion:perPage: 1000
is also repeated in assertNameConflict
. We could create a constant for the 1000.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will extract the all views retrieval into a method
} | ||
``` | ||
|
||
## Update one: `PUT /api/infra/metrics_explorer_views/{metricsExplorerViewId}` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it make sense to document the 400 returned when PUT /api/infra/metrics_explorer_views/0
is called?
} | ||
``` | ||
|
||
## Delete one: `DELETE /api/infra/metrics_explorer_views/{metricsExplorerViewId}` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it make sense to document the 400 returned when DELETE /api/infra/metrics_explorer_views/0
is called?
@crespocarlos thanks for the review, I addressed the comments where we could improve the implementation and updated respectively also the inventory views counterpart to keep them in sync. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Thanks for making the changes.
@elasticmachine merge upstream |
💚 Build Succeeded
Metrics [docs]Module Count
Public APIs missing comments
Async chunks
Public APIs missing exports
Page load bundle
Unknown metric groupsAPI count
ESLint disabled line counts
Total ESLint disabled count
History
To update your PR or re-run it, just comment with: |
📓 Summary
Part of #152617
Closes #155111
This PR implements the CRUD endpoints for the metrics explorer views.
Following the approach used for the InventoryView service, it exposes a client that abstracts all the logic concerned to the
metrics-explorer-view
saved objects.It also follows the guideline provided for Versioning interfaces and Versioning HTTP APIs, preparing for the serverless.
🤓 Tips for the reviewer
You can open the Kibana dev tools and play with the following snippet to test the create APIs, or you can perform the same requests with your preferred client: