[FEATURE]: Implementation of Secure Local PAT Storage and IndexedDB Caching Layer

[swathi2006]

Feature and its Use Cases

To align with the project's "cloud-less" requirement and recent security discussions regarding Personal Access Tokens (PAT), I propose implementing a robust local data management service. This will ensure the application remains functional within GitHub's API rate limits while keeping user data private.

I will implement a decentralized data layer that operates entirely within the user's browser. This system will fetch repository and contributor data for any GitHub organization specified by the user and store it locally to ensure the app remains 'cloud-less' and high-performance.

Key Functionalities:

• Secure Auth Utility: A service to store the user's GitHub PAT in localStorage only, ensuring the token never leaves the client-side environment.

• IndexedDB Schema: A local database to cache organization-wide data (repositories and contributors) to allow the app to work offline or under heavy rate-limiting.

• Cache-First API Client: A logic that checks IndexedDB for existing data before making a GitHub API call, significantly improving performance.

• Multi-Org Support: The caching logic will store data indexed by org_name, allowing users to switch between different GitHub organizations while keeping previously fetched data available offline.

Additional Context

Rate Limiting: Without a PAT, we are limited to 60 requests/hour. This implementation allows up to 5,000 requests/hour, which is necessary for fetching AOSSIE's 60+ repositories.

I plan to use Dexie.js to manage the IndexedDB layer. Using Dexie for high-performance IndexedDB management, ensuring the UI remains "sunny" and responsive even with large datasets.

Data Flow Strategy (Cache-First):

• User enters PAT -> Saved to localStorage (local-only, no server-side handling).

• App requests Org Data -> Service checks IndexedDB first.

• Cache Miss -> Service fetches from GitHub API using the local PAT and populates IndexedDB.

• UI Update -> Data is pulled from the local database to populate the charts and tables.

This approach directly addresses the API rate-limiting issues mentioned in the recent discussions and ensures a "cloud-less" user experience.
Privacy Compliance: Fulfills the requirement for a "cloud-less" architecture where no backend handles sensitive user keys.

Code of Conduct

• I have joined the Discord server and will post updates there
• I have searched existing issues to avoid duplicates

[Sarthakkad05]

@swathi2006 Are you working on this issue?

[swathi2006]

@swathi2006 Are you working on this issue?

Yes, Sarthak! I'm currently setting up the Dexie.js logic for the IndexedDB caching layer. I'm focusing on the 'cloud-less' part of the requirements right now. I'll share an update soon!

[Sarthakkad05]

okay @swathi2006,

One concern: storing the PAT directly in localStorage may have security implications (e.g., exposure via XSS).
Also, from an architectural perspective, since Org Explorer aims to stay lightweight, would it make sense to start with the minimal idb wrapper instead of Dexie?

As this affects core architecture, I think it would be helpful to discuss this on Discord first to align with mentors before proceeding.

[swathi2006]

Thanks for bringing these up, @Sarthakkad05 . Those are very valid points. The XSS risk with localStorage is definitely something we should address, and I'm open to using a more minimal idb wrapper if we want to prioritize bundle size.

I'll head over to the Discord channel now to get the mentor's take on these architectural trade-offs so we can align on the best path forward for the project.