civimobileapi merge requestshttps://lab.civicrm.org/extensions/civimobileapi/-/merge_requests2024-03-26T18:45:02Zhttps://lab.civicrm.org/extensions/civimobileapi/-/merge_requests/78Fixes #73 - Very long load times on event pages2024-03-26T18:45:02ZJonGoldFixes #73 - Very long load times on event pagesMy client insisted I look into the cause of the API slowdown in #73. It ended up being fairly simple.
The API wrapper adds the "registered_participants_count" to every returned event.
If you use `getsingle`, it gets this by (correctly)...My client insisted I look into the cause of the API slowdown in #73. It ended up being fairly simple.
The API wrapper adds the "registered_participants_count" to every returned event.
If you use `getsingle`, it gets this by (correctly) calling `CRM_Event_BAO_Event::getParticipantCount()`. However, if you use `get`, it calls `Participant.get` to get the result count.
This has 2 problems:
* This doesn't give the same value as `getParticipantCount()`, because some registrations aren't counted against the available spaces. E.g. if I have a class with 25 open registrations, registering the teacher with the "Teacher" role shouldn't count against the 25.
* This means that every result in `Event.get` will make a call to `Participant.get`. So if you have 200 events, you're not making 1 API call, you're making 201.
There's a relatively little-known feature of API3 `Event.get`. If you pass the parameter `is_full`, and the event has a registration cap, it will return a value `available_spaces`. This a) gives a correct count, b) saves you all those additional API calls. This resolves the performance issue.
@BohdanDmytryshyn please review and let me know if you agree this is the correct fix?