From Dec 13, 2019 - "Curriculm APIs feel slow". Our previous conversations around this discovered that the Curriculum APIs was being called regularly in order to have accurate Available Seat information for classes during Scheduling periods. Seth had asked if the GoGaucho Team could reduce the number of calls to the API outside or Pass Times, and during Pass Times to limit the number of calls to 2 times per hour. (Seth also mentioned that he would implement 30-minute caching on the Registrar side, so even if there were many calls, they would not affect the performance of the Registrar systems and instead would receive a cached result.)
@Jimmy - This is mostly used by the web app, there emails are ... (Jimmy will send an email after the meeting with their info)
@Diana Antova - Let's add that info into the App Registration / Access Request Form
@Steven Maglio / @Diana Antova / @Seth Northrop - Maybe we could create a separate application for the Web app. Could you ask the Web team to put in a new Access Request form?
@Jimmy - The backend nodejs application is the one that makes the calls, and it is a centralized service which all the front end applications call. So, there is only a single application which makes calls to the API Gateway.
Documentation on the API can be confusing, can it be improved?
Sometimes the data will have and sometimes it will have spaces, so it can feel inconsistent.
Example - Course ID - The description says 13 characters, but it's not always 13 characters (@Steven Maglio - Right Trim is occurring).
Follow-up for Jun 2, 2020: Were you think that column should always be 13 characters?
Shiheng - When they receive the data, they compress the whitespace string down; so they are changing the format anyways.
Who are going to be the leads
Jun 2, 2020 Do you have any needs on your mind?
Shiheng - On the Curriculums API - Could the finals information be included with the classes/classsections response? Maybe it could be a parameter on the call (includeFinals)?
@Seth Northrop - That’s something we could look into. It’s a bit awkward because the legacy database structure makes it so we have to combine some disconnected data; which can have performance impacts. (And, we’ve had some performance impacts with the curriculums API which have had unexpected/adverse side effects).
Henry - Public Records - The GoGaucho team has put in a request to the Public Records office to get a dump of historical grade distribution information (distributions from classes over time). They haven’t heard back. (They saw another website that had access to the data and asked them how they received the data; the other website said they just asked the Public Records office for it).
@Steven Maglio - I do remember an email thread about this but, I asked the GoGaucho team to send over any information they have on the thread to Diana, Seth, and myself so that we can write it down someplace as a possible future API to put into the system. I also explained that Campus is dealing with COVID-19 related work right now, so the hope would that information about the API would be written down on the roadmap so it can be a reminder to look at again once the Campus has more available resources.
UCSB Improvements & Timeline
UCSB Team GoGaucho Team
Apr 24, 2020
From Dec 13, 2019 - "Curriculum APIs feel slow".
Does the Registrar's Curriculum endpoint have the 30-minute caching in place?
Jun 2, 2020 - This is done for version 1 (May 7, 2020), but version 2 is being worked on.
There were plans to implement another endpoint specifically for this need. (the Availability Count for a Class) Hows that going?
@Seth Northrop - That's a ticket, but it is competing against other priorities. It's really hard to prioritize against the immediate needs (COVID-19 is also having a impact). There was also more pressure to get this in place due to performance issues that were happening on the system. With some recent reconfigurations/updates those performance issues have reduced, so the pressure is reduced. https://ucsb-sist.atlassian.net/browse/RGOPERATIONS-1223
Jun 2, 2020 - Version 2 - There were different needs for caching on the different endpoints. The different endpoints have different response sizes (for example: the full quarter dump), which seems to be larger than the maximum size of the cache. So, there is some work to determine on what’s the best way to handle the performance on this (maybe moving away from caching towards paging?).
@Seth Northrop - Would it be fine if this was broken up into multiple calls?
Shiheng - That should be fine.
Curriculum performance has come up in other venues, are there any other changes being planned for?
@Seth Northrop - The Curriculum blocking issue is getting close to being resolved, due to implementations of the caching and endpoint from above.
Jun 2, 2020 - @Seth Northrop asks - Are you seeing improved response times for the endpoint?
Shiheng - I guess, but we haven’t really been actively monitoring it. This is done automatically (on a scheduled basis) and it’s meeting our needs.
Jun 2, 2020 - @Seth Northrop - Is the team planning on continuing developing over the summer?