-
Notifications
You must be signed in to change notification settings - Fork 0
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
Conversation
It allows to group_by on a column and count the check occurences for a selected date
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, great job! A few optional questions/remark if we want to go further.
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` |
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.
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.
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 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 agroup_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.
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.
Fair enough then, let's keep it that way. Thanks for the explanation!
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 am leaving it unresolved as it may be useful reference for future readers.
By the way, it's much better than this: |
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