“Who unfollowed me?” is a common question, but from a software engineering perspective, answering it for accounts with thousands of followers becomes a challenge of data fetching, rate limiting, and algorithmic efficiency.

In this article, I’ll walk through how I built the Social Graph Analyzer, focusing on creating a rock-solid, production-ready backend foundation using Node.js and Express, along with a clean and responsive frontend built with Next.js.

The Architecture: Separation of Concerns (SoC)

Rather than writing a monolithic “spaghetti” script, I organized the project into modular layers. This ensures that the code is maintainable and ready for future integrations (like adding LinkedIn or Twitter support).

• GitHub Client: A dedicated Axios instance that handles base URLs, timeouts, and authentication tokens globally.
• Pagination Helper: A utility designed to parse GitHub’s Link headers, enabling the system to traverse through thousands of records across multiple pages seamlessly.
• Service Layer: This layer encapsulates the “how” of data fetching, isolating the API logic from the rest of the application.

Algorithmic Efficiency: Why I Chose Set

When comparing two lists (Followers vs. Following), using nested loops would result in O(n²) time complexity. For a user with 10,000 followers, this would be painfully slow.

By leveraging JavaScript’s Set object, I reduced the lookup time to O(1) on average. This brought the overall comparison complexity down to O(n), allowing the analyzer to process thousands of entries in milliseconds once the data is fetched.

O(n²) → O(n)

Handling API Constraints

Building on top of third-party APIs requires respect for their limits. I implemented:

• Rate Limit Management: Integrating Personal Access Tokens (PAT) to boost GitHub’s hourly limit from 60 to 5,000 requests.
• Safety Boundaries: Implementing a MAX_ITEMS cap to prevent the synchronous execution from timing out on "celebrity-scale" accounts.

What’s Next?

This stage was about building the ‘Brain’ of the analyzer. The next steps involve transitioning to a Worker/Queue architecture to handle massive accounts without timing out.