DEV Community

Vinh Nhan
Vinh Nhan

Posted on

Hacktoberfest 2024 - Week 1: Handling GitHub API Rate Limits in GitExplorer

Hello! 👋

I'm excited to kick off my Hacktoberfest journey this October with a project I'm contributing to called GitExplorer. GitExplorer is a web application that helps users discover and explore GitHub repositories based on various criteria like programming language, topics, and sorting by stars or forks. It's an excellent tool for anyone who wants to quickly find repositories for a specific purpose or interest.

This week, I worked on Issue #1 for GitExplorer: GitHub API rate limit feedback. The issue involves handling GitHub's search API rate limits. Since GitExplorer uses the search API, which limits requests to 10 per minute, frequent searches could cause users to hit the rate limit. My task was to improve user feedback when this happens.

What the Issue Was About

The GitHub search API enforces a limit of 10 requests per minute for unauthenticated users. Once users exceed this limit, they won’t be able to make any more searches until the timer resets. The problem was that GitExplorer didn’t provide any feedback when the rate limit was reached, potentially leaving users confused when search results suddenly stopped appearing.

Preparation for the Fix

To prepare, I had to look at how GitExplorer interacts with the GitHub API. I needed to understand where the response headers containing the rate limit data were being handled, and how to access and display this information to the user. There wasn’t too much setup involved, as I could easily add the logic to existing API request functions.

Learning Points

In order to address this issue, I needed to learn more about how to handle response headers in JavaScript, specifically the X-RateLimit-Remaining and X-RateLimit-Reset headers returned by GitHub's search API. I also explored various ways to handle errors and display messages in a user-friendly manner on the UI.

The Code Explained

Here’s a breakdown of how I tackled the issue:

  • I added logic to retrieve the rate limit headers from the API response.
  • If the remaining rate limit (rateLimitRemain) is less than 5, the app displays a warning message in the UI using a <p> element with the ID #rateLimitMessage.
  • If the rate limit is exhausted (rateLimitRemain is 0), I throw an error. The error message is both logged to the console and displayed on the UI, informing users how long they need to wait before they can make another search. The rateLimitReset value tells users the exact time (in seconds) when the rate limit will reset.

This ensures users receive a clear warning when approaching the limit and are properly informed when they've hit the limit.

Research and Challenges

To better understand how to handle rate limit responses, I reviewed GitHub’s API documentation. I also had to figure out the best way to present the rate limit reset time in a user-friendly format, converting the X-RateLimit-Reset value into a readable timestamp.

Interesting Interactions

I had a helpful interaction with the project maintainer, Rahul Kumar, who suggested prompting user to log in to increase the API request limit. Since GitExplorer currently doesn’t support log-ins, I focused on improving the feedback for unauthenticated users for now, but adding a login feature and prompt could be a great future enhancement.

Difficulties and Solutions

One of the biggest challenges was understanding how GitHub's rate limit system works and retrieving the appropriate headers from the API response. I had to ensure I was correctly handling the X-RateLimit-Remaining and X-RateLimit-Reset headers, which required careful reading of GitHub's API documentation. Once I figured out how to access these headers, the next hurdle was displaying the information in a way that was clear to users without interrupting the flow of the application.

Pull Request

You can check out my full work and the discussion in the Pull Request here: PR #18.


This wraps up Week 1 of my Hacktoberfest 2024 contributions. It was a great learning experience, and I’m excited to tackle more issues in the upcoming weeks.

Thanks for following a long my open-source learning journey!

Top comments (0)