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

Add checks aggregate route #167

Merged
merged 8 commits into from
Sep 24, 2024
Merged

Add checks aggregate route #167

merged 8 commits into from
Sep 24, 2024

Conversation

maudetes
Copy link
Contributor

@maudetes maudetes commented Sep 17, 2024

It allows to group_by on a column and count the check occurrences for a selected date.
Useful for debugging current checks trends, ex:

Notes

  • This is probably not the most REST logic route, so I would be interested in alternative implementations.
  • Param parsing is very naive currently and would fail on non valid values
  • I was wondering if we should follow these group_by indicators in a Munin plugin instead?

It allows to group_by on a column and count the check occurences for a selected date
Copy link
Contributor

@bolinocroustibat bolinocroustibat left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, great job! A few optional questions/remark if we want to go further.

README.md Outdated Show resolved Hide resolved
README.md Outdated
@@ -116,6 +116,7 @@ The API serves the following endpoints:
*Related to checks:*
- `GET` on `/api/checks/latest/?url={url}&resource_id={resource_id}` to get the latest check for a given URL and/or `resource_id`
- `GET` on `/api/checks/all/?url={url}&resource_id={resource_id}` to get all checks for a given URL and/or `resource_id`
- `GET` on `/api/checks/aggregate/?group_by={column}&created_at={date}` to get checks occurences grouped by a `column` for a specific `date`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about /api/checks?group_by={column}&created_at={date} instead? Maybe it is as explicit?
Isn't the aggregation an internal mecanism which doesn't need to be explicited in the URL?
Or, do we need to have an aggregate in the URL to differentiate other future type of search parameters?
Just raising the question, but might be more difficult to separate the routes in the code that way.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wanted to start with this approach, but I had some considerations:

  • the payload would vary greatly depending on group_by being used or not.
  • It also does not actually return checks objects per se, it returns count aggregation.
  • Since we did not have any existing GET /api/checks, it seemed weird to require a group_by parameter on this route. It made me think that /api/checks/latest and /api/checks/all should probably be /api/checks with additional relevant params (pagination would do actually). Thus going with /aggregate path for now. A refactoring may follow to standardize /api/checks routes maybe.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair enough then, let's keep it that way. Thanks for the explanation!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am leaving it unresolved as it may be useful reference for future readers.

README.md Outdated Show resolved Hide resolved
@bolinocroustibat
Copy link
Contributor

By the way, it's much better than this:

https://x.com/excid3/status/1836042970472075673

@maudetes maudetes merged commit ef5c71d into main Sep 24, 2024
4 checks passed
@maudetes maudetes deleted the feat/add-checks-aggregate-route branch September 24, 2024 10:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants