多客户端相似REST API请求合并优化方案咨询（排除GraphQL与缓存方案）

Great question—let’s break down some practical, lightweight solutions that fit your constraints perfectly. You don’t need overkill GraphQL or forbidden caching to reduce redundant network calls and optimize data fetching. Here are your top options:

1. Request Aggregation Layer (Lightweight Middleware) #

This is the most flexible approach if you can’t modify your existing REST backend. Build a thin middleware layer (think Node.js/Express, Java Spring Boot, or Python FastAPI) that sits between your clients and the REST API. Here’s how it works:

• The layer listens for incoming client requests and groups identical requests (e.g., multiple calls to /api/products/123) within a short time window (like 50-100ms).
• It sends one single request to the backend API instead of multiple duplicates.
• Once it gets the response, it splits the data and returns it to each waiting client.

Key Details: #

• Use in-memory tracking (like a hash map of pending promises) to avoid duplicate requests—this is not persistent caching (just temporary request-level coordination, which should avoid your licensing restrictions).
• Example snippet (Node.js/Express):

  const pendingRequests = new Map();
  
  app.get('/api/products/:id', async (req, res) => {
    const productId = req.params.id;
    // Check if a request for this ID is already in flight
    if (pendingRequests.has(productId)) {
      const promise = pendingRequests.get(productId);
      const data = await promise;
      return res.json(data);
    }
    // No pending request—initiate one
    const fetchPromise = fetch(`https://your-rest-api.com/api/products/${productId}`).then(res => res.json());
    pendingRequests.set(productId, fetchPromise);
    // Clean up after the request completes
    fetchPromise.finally(() => pendingRequests.delete(productId));
    const data = await fetchPromise;
    res.json(data);
  });
  

• Pros: No backend changes needed, works with any client.
• Cons: Requires maintaining an extra middleware service.

2. Custom Bulk API Endpoints #

If you have control over your REST backend, adding bulk endpoints is the most efficient solution. Instead of forcing clients to make repeated single-resource calls, create endpoints that accept multiple IDs at once:

• Example: Replace repeated calls to /api/users/{id} with a single call to /api/users/batch that accepts a list of IDs (e.g., POST /api/users/batch with body {"ids": [1,2,3]}).
• Your backend can then fetch all requested resources in one database query (instead of multiple round-trips) and return a mapped response.

Key Details: #

• Your middleware (or even clients directly) can aggregate individual requests into a single bulk call.
• Pros: Minimizes database and network overhead, most performant option.
• Cons: Requires modifying your backend API.

3. Client-Side Request Coalescing #

If your clients are under your control (e.g., a React frontend, iOS/Android app), implement request merging directly on the client side:

• Use a utility function or library that collects identical requests within a short window and sends a single combined request.
• Example in React: A custom hook that batches getUser(id) calls into a single getUsers([id1, id2, id3]) call after a 100ms delay.

Key Details: #

• This reduces the number of requests hitting your server entirely.
• Pros: No server-side changes needed, reduces network traffic at the source.
• Cons: Only works if you control all client implementations.

4. Reverse Proxy Request Coalescing #

Leverage existing reverse proxy tools (like Nginx or Envoy) to handle request merging without writing custom code:

• Nginx: Use the ngx_http_upstream_module with configuration to buffer and merge identical requests.
• Envoy: Enable the request_coalescing filter, which automatically groups identical requests to the same upstream endpoint.

Key Details: #

• This is a "set it and forget it" solution if you already use a reverse proxy.
• Pros: No custom code, non-intrusive to your API and clients.
• Cons: Less flexible than a custom aggregation layer (limited to identical request paths/parameters).

Final Recommendation #

• If you can’t modify your backend: Go with a Request Aggregation Layer or reverse proxy coalescing.
• If you control the backend: Build Bulk API Endpoints for maximum efficiency.
• If you control all clients: Add Client-Side Coalescing to reduce request volume at the source.

内容的提问来源于stack exchange，提问作者cytings