GitAuto: A performance of a page (/settings/integrations/jira) is too slow. #143
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Resolves #133
Why the bug occurs
The
/settings/integrations/jira
page experiences slow performance primarily due to multiple redundant calls to theget-installed-repos
API endpoint. Each call with differentinstallationId
parameters results in significant delays, cumulatively leading to an excessive page load time of approximately 15.43 seconds. This redundancy not only increases the server processing load but also leads to inefficient network utilization.How to reproduce
/settings/integrations/jira
page in the application.get-installed-repos
requests with differentinstallationId
values being made sequentially.Where / How to code and why
Backend Optimization
File:
app/api/github/get-installed-repos/route.ts
Changes:
Implement Caching: Introduce caching mechanisms (e.g., in-memory caching using
node-cache
or integrating Redis) to store responses of frequently accessedinstallationId
s. This reduces the need for repetitive database queries and accelerates response times.Batch Processing: Modify the endpoint to accept multiple
installationId
s in a single request, allowing the server to process and return data for all requested installations at once. This minimizes the number of API calls and reduces overall latency.Reasoning: Caching reduces redundant database access, and batch processing decreases the number of network requests, both of which contribute to improved performance.
Frontend Optimization
Files:
app/settings/integrations/jira/useIntegrations.ts
app/settings/integrations/jira/useRows.ts
app/settings/integrations/jira/JiraForm.tsx
Changes:
Consolidate API Calls: Refactor the frontend logic to gather all necessary
installationId
s and make a single batched request to the optimizedget-installed-repos
endpoint. This can be achieved by aggregating the IDs before making the API call.Implement Debouncing: Introduce debouncing strategies to prevent rapid successive calls to the API when the component mounts or when certain state changes occur.
Utilize SWR or React Query: Adopt data fetching libraries like SWR or React Query to handle caching, request deduplication, and automatic retries, enhancing data management and reducing unnecessary requests.
Reasoning: Consolidating API calls reduces the number of server interactions, debouncing prevents unnecessary rapid requests, and leveraging data fetching libraries ensures efficient and optimized data handling on the frontend.
Additional Enhancements
Monitoring and Logging: Enhance server-side logging to monitor the performance of the
get-installed-repos
endpoint post-optimization. This ensures that caching and batching are functioning as intended and helps in identifying any unforeseen issues.Error Handling: Improve error handling mechanisms to gracefully manage scenarios where the batched requests might fail, ensuring a better user experience.
Anything the issuer needs to do
No action required.
Test these changes locally