-
Notifications
You must be signed in to change notification settings - Fork 90
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
[Looking for feedback]: Adds partnerAlertsConnection + partnerCollectorProfilesConnection #5826
base: main
Are you sure you want to change the base?
Conversation
Co-authored-by: Lily Pace <[email protected]>
Co-authored-by: Lily Pace <[email protected]>
|
...connectionFromArraySlice(collectorProfiles, args, { | ||
arrayLength: collectorProfiles.length, | ||
sliceStart: offset, | ||
}), |
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.
(We'll want to use our paginationResolver
pattern like we did in the file above here)
{ partner_id: string; user_ids: string[] } | ||
>( | ||
({ partner_id, user_ids }) => { | ||
const userIdsParams = user_ids.map((id) => `user_ids[]=${id}`).join("&") |
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.
not-blocking: do we need to worry about the max length of a query string? not sure what is the max number of collector profiles we'll want to show at one time for a given alert, but I can see this exceeding limits for alerts with lots of collectors.
totalCount: { | ||
type: GraphQLBoolean, | ||
}, |
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.
thought: It strikes me as un-idiomatic for an MP field to take totalCount
as an arg. I see only one case of this but many, many more where we request the total count from Gravity by default (search repo for total_count: true
).
I think some pagination logic even relies on that total count being present, so perhaps better to include it by default?
Furthermore… I believe this query is ultimately fulfilled by ES, yes? If so I think that total count is always computed and doesn't even make sense as an arg (in which case this arg over in the upstream Gravity endpoint might be totally superfluous).
headers: { | ||
"x-total-count": 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.
Related to my other comment — this header is actually out of sync with the invocation on L1451, since totalCount: true
wasn't provided? This becomes a non-issue if you take my suggestion in the other comment.
Looking for feedback!
Adds
partnerAlertsConnection
andpartnerCollectorProfilesConnection
to return partner facing alert data + associated user collector profile detailsIs it ok to have nested connections?
In this PR
Adds
partnerAlertsConnection
underpartner
that makes API call to Gravity'sapi/v1/:partner_id/partner_search_criterias
endpoint which returns a list of PartnerSearchCriteria:Ex from Gravity
After MP receives the Gravity response, we take the
user_ids
from the response and fetchcollector profile data in a batch to the new endpoint
api/v1/partner_collector_profiles?user_ids[]=blargh&user_ids[]=bar
here
Allows for pagination + querying alerts and collector profiles
Some query examples:
Partner search criteria first ten 5 + top 2 Collector profiles
Response:
Partner search criteria and give us 10 Collector profiles
Response
Example:
TODOs: