guillermo
commented
8 months ago Sorry. I think you mentioned the wrong @guillermo. Maybe @GuillermoFloresV ?
Open ngillux opened 8 months ago
guillermo
commented
8 months ago Sorry. I think you mentioned the wrong @guillermo. Maybe @GuillermoFloresV ?
ngillux
commented
8 months ago Sorry. I think you mentioned the wrong @guillermo. Maybe @GuillermoFloresV ?
Yes, sorry about that! :)
[ISSUE RESERVED FOR CTI STUDENT(S)]
The problem (via @GuillermoFloresV ) 07/30/2023:
Recently, we came across an issue that seems to have originated from changes on the FCC backend. Our API processing file (/util/api_processor) started creating undefined data inside the allChallenges key inside our CreateDashboardObject function.
The fault came from attempting to access a zeroth index inside of our response object. We did some digging and found that the issue persists despite rolling back changes made to the processing file and files associated with it, leaving us with the assumption that this was caused by changes in the FCC API that we use to build and display classrooms.
The following screenshot shows what maintainers/contributors/potential end-users would have seen (a potentially hard to interpret error message + unaddressed edge case for end-users).
NOTE: The error was debugged and is currently not an issue. This task will add maintainability and scalability if this scenario was to ever arise again.
Why it’s bad:
If the shape or data types of the API data changes, this will affect the current logic that uses the previous shape of the API response.
Currently there is no mechanism in place that alerts maintainers of API changes. There is also no mechanism in place to detect these changes in the current logic. This could result in users (maintainers, contributors or beta-testers) to see an erroneous UI.
For the time being, a solution could be to have users just see a ‘Under construction … ‘ type message until maintainers/contributors can update the code / logic to match the new API response data. And in another iteration, there could be a mechanism that prevents the new API response data to be used if it breaks code elsewhere that relies on the current API response data.
Task:
Implement logic/UI to address broken project state caused by potential API updates/changes (broken dashboards, traversals, etc.).
New expected behavior:
Improved response time to update logic + bug tracking for maintainers/contributors. This change will modify both what the end user sees (UI), as well as the ‘under the hood’ functionality. The end user will see a meaningful message instead of a confusing error. For contributors/maintainers, when they’re working on the project they will also be able to see this message and will be able to quickly identify it’s due to an API update/change, instead of potentially spending hours trying to figure out the catalyst for the bug.
Good to know(s): Next.js caches under the hood.
React (which extend the fetch API) can perform Request Memoization . This means that although you may see multiple ‘fetch’ requests to the same URL/API endpoint in React components, the request is only executed once. So instead of making 1 API request, and passing data through props, React allows for making multiple requests in the component hierarchy without affecting performance (due to changes).
You can read more about it here - jump to ‘Request Memomization.’
Implementation suggestions / ideas: See if there is a way to prevent the cached data being updated if there is a change in the API response. The reason this is important is maintainers/contributors need to be updated if the new API response will break existing logic. If the new API response does not break existing logic, the old data can then be replaced and the new data can be cached.
Possible resources: