You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The most used call in groups API is plan old "/v5//groups/:groupId". This is because challenge-api needs to determine:
Step 1: Get all the groups the user directly belongs to (which is often > 1000).
Step 2: For each of those groups, get all the parent groups of that group
Step 3: Combine all these group IDs together
Step 2 makes a separate call for every group returned from Step 1, so a single call to challenge-api often results in over 1,000 calls to groups api:
3 Hour chart
2.3 Million calls to groups API in 3 hours due to this (this is typical across any 3 hours).
You can inspect the logic of exactly what it's doing by following helper.getCompleteUserGroupTreeIds
The suggested solution here is to implement a param such as /v5/groups?includeParentGroups=true which implements this logic so that it can be removed from challenge-api and handled in groups-api (via neo4j directly).
The text was updated successfully, but these errors were encountered:
@dushyantb , the groupeligibilitycheck endpoint only returns a check:true/false . How do we get the list of groups the user has access to (including parent groups) ?
Do we use the groups/MemberGroups/{oldMemberId} endpoint instead? This returns the list of groups including the parent groups, but it returns only the list of old group ids. The challenge-api will need to make further calls to get additional data for each of those groups.
Groups micro-service already has an Api that returns all the groups accessible by a member. It has now been updated to return UUIDs which can be used by Challenge Api to reduce number of Api calls to get a members accessible groups in this commit d1ff097
The most used call in groups API is plan old "/v5//groups/:groupId". This is because challenge-api needs to determine:
Step 1: Get all the groups the user directly belongs to (which is often > 1000).
Step 2: For each of those groups, get all the parent groups of that group
Step 3: Combine all these group IDs together
Step 2 makes a separate call for every group returned from Step 1, so a single call to challenge-api often results in over 1,000 calls to groups api:
3 Hour chart
2.3 Million calls to groups API in 3 hours due to this (this is typical across any 3 hours).
In challenge-api this process begins here: https://github.com/topcoder-platform/challenge-api/blob/1249f141c194229386f6bcf694fda138a9ca82ae/src/services/ChallengeService.js#L400
You can inspect the logic of exactly what it's doing by following
helper.getCompleteUserGroupTreeIds
The suggested solution here is to implement a param such as
/v5/groups?includeParentGroups=true
which implements this logic so that it can be removed from challenge-api and handled in groups-api (via neo4j directly).The text was updated successfully, but these errors were encountered: