Add a shared SWR-style in-flight request dedupe layer to apiRequest GET calls

[Jagadeeshftw]

📌 Description

useOptimisticData caches per hook instance via its own cacheRef, so two components mounting simultaneously (e.g. DiscoverPage and a nav widget both calling getLandingStats/getPublicProjects) each fire their own request. Add a small in-flight dedupe map keyed by endpoint+query at the apiRequest GET layer so concurrent identical GETs share a single promise. This reduces duplicate network traffic without a heavy data-fetching library.

💡 Why it matters: Independent components requesting the same public data multiply network load and backend pressure.

🧩 Requirements and context

• Maintain a module-level Map<string, Promise<unknown>> for in-flight GETs.
• Key on method+url; only dedupe idempotent GET/HEAD.
• Clear the map entry on settle (resolve or reject).
• Never dedupe authenticated mutating requests.
• Make dedupe opt-out via an option for callers that need a fresh request.

Non-functional requirements

• Must be secure, tested, and documented.
• Should be efficient and easy to review.

🛠️ Suggested execution

1. Fork the repo and create a branch

git checkout -b perf/api-inflight-dedupe

2. Implement changes

• Write/modify the relevant source: src/shared/api/client.ts
• Write comprehensive tests: src/shared/api/client.test.ts
• Add documentation: inline TSDoc on the dedupe behavior
• Include TSDoc doc comments
• Validate security assumptions: auth and abort signals respected per caller

3. Test and commit

• Run tests:

npm test -- client

• Cover edge cases: concurrent identical GETs share a promise; rejection clears the entry; aborts isolated per caller
• Include test output and security notes in the PR description.

Example commit message

perf(api): dedupe concurrent identical GET requests

✅ Acceptance criteria

• Concurrent identical GETs issue one fetch
• Map entry cleared on settle
• Mutations never deduped
• Opt-out option works

🔒 Security notes

Only dedupe by URL+method for unauthenticated GETs to avoid leaking one user's response to another via shared promises.

📋 Guidelines

• Minimum 95% test coverage
• Clear documentation
• Timeframe: 96 hours

[moff-tarkin]

My approach would be to review the existing request layer, identify where duplicate GET requests occur, and implement a reusable in-flight deduplication mechanism that integrates cleanly with the current architecture.

[samuelca12]

Hey! I'd like to take this on. I'll implement the in-flight dedupe map at the apiRequest GET layer, keyed by method+url, with proper settle cleanup, mutation exclusion, and an opt-out flag for fresh requests. I'll include comprehensive tests covering concurrent GETs, rejection cleanup, abort isolation, and security boundaries, plus inline TSDoc. Ready to start. I'd finish before the Grantfox campaign closes!

[GBOYEE]

Approach

1. Dedupe map — Create in-flight request cache (Map<string, Promise>) keyed by serialized URL+params
2. Wrapper — Intercept apiRequest GET calls: if identical request is in-flight, return existing promise
3. TTL — Auto-clear entries after configurable window (default 5s) to prevent stale deduplication
4. Cache layer — Optional: add SWR-style stale-while-revalidate with configurable revalidateOnFocus
5. Bypass — Allow force-refetch option for critical data
6. Tests — Verify concurrent identical calls return same promise, sequential calls create new requests

Clean abstraction. Ready now.

[clintjeff2]

Hello, I have 6 years of experience working on tasks like this and handling similar challenges across backend, frontend, and smart-contract development. I have carefully read and fully understood the task requirements, and I am confident I can deliver a clean, efficient, and well-tested solution promptly. I always ensure high-quality implementation, maintainability, and adherence to best practices.

Pull request in 5 hours.

[JuliobaCR]

Hi Grainlify team,

I want to work on this issue because the root problem is clear and well-scoped: useOptimisticData's per-instance cacheRef means two components mounting simultaneously (e.g. DiscoverPage + a nav widget calling getLandingStats) each fire independent fetches for identical data, multiplying backend load without adding value.

Problem understanding:
The fix must live at the apiRequest GET layer — not in individual hooks — so deduplication is transparent to all callers. The key insight is that the dedupe map must hold Promises, not responses, so concurrent callers naturally share the in-flight request and each gets the same settled value.

My approach:

1. Add a module-level Map<string, Promise<unknown>> in src/shared/api/client.ts, keyed by method + url (serialized).
2. On each GET/HEAD call: if the key exists in the map, return the existing Promise directly.
3. On settle (both resolve and reject): delete the map entry to prevent stale deduplication.
4. Never apply deduplication to authenticated or mutating requests (POST/PUT/PATCH/DELETE).
5. Add a { dedupe: false } opt-out option for callers that explicitly need a fresh request.
6. Ensure each caller's AbortSignal is handled independently — abort from one caller must not cancel the shared fetch for other callers (this is the trickiest edge case and I'll handle it by tracking signal listeners separately).

Tests I will cover:

• Concurrent identical GETs return the exact same Promise instance
• Rejection clears the map entry so the next call retries
• Mutations are never deduped
• Abort from one caller does not affect others sharing the same in-flight request
• { dedupe: false } option forces a new request

Security note: I'll ensure deduplication only applies to unauthenticated public GETs — any request with an Authorization header will bypass the dedupe map entirely to prevent leaking one user's response to another.

Estimated time: 2 days (48 hours) — 1 day for implementation + TSDoc, 1 day for comprehensive test coverage ≥95% and PR write-up with security notes.

I have experience building shared API client layers in TypeScript, managing Promise lifecycles, and writing test suites for async edge cases. I'll deliver a focused, reviewable PR that touches only client.ts and client.test.ts.

[gloskull]

Hi, I’d love to work on this issue. I have 4 years of experience across backend, frontend, full-stack, and smart contract development. I understand the task clearly and can deliver a clean, efficient, well-tested solution on time, with strong focus on code quality and maintainability. My PR will be submitted in under 10 hours.