Cap API client response cache with LRU eviction

[RUKAYAT-CODER]

Background

The in-memory response cache grows without bound. Add an LRU cap with a configurable size.

Files to modify (2-3)

src/lib/api.ts
src/constants/app.constants.ts

Acceptance Criteria

Implemented across the listed files

Unit/integration tests added or updated and passing

No regression; follows project coding standards

[Paranoa-dev]

I’d like to work on this issue because an unbounded in-memory response cache can become a long-running memory leak, especially as the number of unique API requests increases. Introducing an LRU (Least Recently Used) limit provides predictable memory usage while retaining the performance benefits of caching frequently accessed responses.

I would first inspect the current cache implementation in src/lib/api.ts and determine how cache keys, response values, expiration, and invalidation are currently handled. I would then introduce a configurable maximum cache size through src/constants/app.constants.ts, using a sensible default that preserves existing behavior for normal workloads.

The cache would follow true LRU semantics:

• New entries are added normally.
• Accessing an existing entry marks it as recently used.
• When the configured capacity is exceeded, the least recently used entry is removed.
• Updating an existing entry refreshes its position in the LRU order.
• Existing cache expiration/invalidation behavior remains intact.
• A configurable limit allows deployments to tune memory usage without modifying the cache implementation.

I would keep the change isolated to the requested files and avoid introducing unnecessary dependencies if the existing project structure allows the LRU behavior to be implemented cleanly with the current data structures.

Tests would cover:

• Entries being cached and retrieved normally.
• Recently accessed entries being retained.
• The least recently used entry being evicted when the maximum size is exceeded.
• Updating/accessing an entry correctly refreshing its LRU position.
• The configured cache size being respected.
• Existing expiration and cache behavior continuing to work.
• Edge cases such as a cache size of 0 or 1, according to the project's expected configuration semantics.
• Ensuring eviction does not affect unrelated API requests.

I would also run the existing unit/integration test suite and verify lint/typecheck/build requirements where applicable.

This is a good fit for me because it is a focused performance and reliability improvement that addresses unbounded memory growth without changing the public API behavior. The resulting cache will have predictable memory usage while still providing effective response reuse for frequently accessed data.

[Killerjunior]

@Killerjunior has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Hi maintainer, I have read and understood the issue requirements and checked the necessary documentation. I’m confident I can work on this task effectively and deliver a proper solution.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Killerjunior to this issue.

[okoye-collins]

@okoye-collins has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Hey, maintainer, I will take up this issue.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @okoye-collins to this issue.

[flexocode442]

@flexocode442 has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Hello Maintainer, I’ve reviewed the issue description and I’m confident I can work on it effectively. Please assign it to me.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @flexocode442 to this issue.

[CollinsKRO]

@CollinsKRO has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Hi, I can fix this

ℹ️ Repo Maintainers: To accept this application, review their application or assign @CollinsKRO to this issue.

[Peaostrel]

@Peaostrel has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

i can handle this quickly

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Peaostrel to this issue.

[drips-wave]

Congratulations, @Killerjunior! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on August 31, 2026.

🧑‍💻 @Killerjunior: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊

[grantfox-oss]

🎉 This issue has been marked as completed on GrantFox!

@Killerjunior's PR #1310 was approved and merged by @RUKAYAT-CODER.

🏆 @Killerjunior: You earned 45 FoxPoints for this contribution! Your current tier: Specialist (3,338 total points). Track your full progress on GrantFox.

👏 Great work, @Killerjunior! Keep contributing to rinafcode.