`fetch-limit`: The Smallest Possible Library With the Biggest Performance Question

Aiden Bai’s outbound-request throttle is still just a promise on GitHub, which makes the interesting part not the code, but the design pressure behind it.

4 to 6 min read • View on GitHub • More from aidenybai

A narrow gate controls a stream of identical packets moving along a conveyor belt, with only a few allowed through at once while the rest wait in a tidy queue behind it. The image explains bounded parallelism: concurrency limiting is less about stopping work and more about regulating flow. — Concurrency limiting is a queueing problem dressed up as a tiny utility.

Key Takeaways

`fetch-limit` is interesting before it exists, because the repo reads like a public bet on a very specific performance problem.
The real challenge is not slowing requests down, but turning a burst of `fetch` calls into bounded parallelism with predictable queue behavior.
A good limiter has to preserve native `fetch` ergonomics while staying cheap enough to disappear inside real applications.
Compared with generic concurrency wrappers, a fetch-specific utility only matters if it can make control feel native instead of bolted on.

A library that is mostly an idea

`fetch-limit` is almost empty, and that is the point. There is no implementation to review, no package surface to audit, and no benchmark to trust. What exists is a name, a description, and a signal: somebody thinks outbound request throttling is worth naming early.

That matters because the author is Aiden Bai, whose work has a strong performance bias. A tiny repo from a performance-minded builder is never just a tiny repo. It is a clue about where the attention will go when the code shows up.

Why concurrent fetches become a problem so quickly

A burst of `fetch` calls looks harmless until it meets reality. Browsers have connection limits. APIs rate-limit. Servers spike. Memory grows. User interfaces stall while a wall of pending promises waits for the network to catch up.

Concurrency limiting is useful because it solves the shape of the problem, not just the symptom. You do not always want fewer requests. You want a controlled number of active requests and a queue for everything else.

A limiter is a tiny scheduler. It turns overflow into a queue and releases work only when capacity opens up.

What a good limiter actually has to do

The easy version of a limiter is just a counter: if fewer than N tasks are active, start another one. The hard part is everything around that rule. Calls have to return the right values, failures have to propagate cleanly, queued work has to wait fairly, and the wrapper should not add much overhead of its own.

function limitFetch(maxConcurrency) {
  let active = 0;
  const queue = [];

  const runNext = () => {
    if (active >= maxConcurrency || queue.length === 0) return;
    const { input, init, resolve, reject } = queue.shift();
    active++;

    fetch(input, init)
      .then(resolve, reject)
      .finally(() => {
        active--;
        runNext();
      });
  };

  return (input, init) => new Promise((resolve, reject) => {
    queue.push({ input, init, resolve, reject });
    runNext();
  });
}

A close-up control panel with three linked dials and a single lever, showing active requests, queued requests, and released requests as part of one mechanism. The image explains that a limiter is a small scheduler, not just a counter. — The mechanism matters. A limiter is arbitration logic, not just a number.

Why this repo is interesting because of who is behind it

Aiden Bai does not need much introduction in JavaScript circles. His reputation changes how this repo is read. A generic utility stub looks like a placeholder. A performance-oriented builder’s utility stub looks like a promise that the implementation will care about overhead, ergonomics, and sharp edges.

That is the real editorial value here. `fetch-limit` is not compelling because it already competes with anything. It is compelling because it advertises a problem space in the vocabulary of someone who tends to care about the cost of every abstraction.

How `fetch-limit` would likely differ from a generic `p-limit` wrapper

Dimension	Promise.all burst	Generic limiter	Fetch-specific limiter
Ergonomics	Simple, but no control	Flexible, but generic	Closest to native `fetch` usage
Concurrency control	None	Explicit max concurrency	Explicit max concurrency
Queue behavior	Everything starts at once	Queued tasks wait for release	Queued tasks wait for release
Overhead	Minimal, but uncontrolled	Adds a wrapper layer	Should stay tiny and fetch-native
Best fit	Small batches	Broad async orchestration	Outbound request throttling

The point of a `fetch`-specific library is not that it can do something generic libraries cannot. The point is that it can make the common case feel native. If it is well designed, the limiter disappears into the request flow instead of announcing itself at every call site.

The promise of a public placeholder

This repo is a public draft. That is a valid open-source move. Sometimes the repository name is the first committed design decision, and the code arrives later once the shape of the problem is clear enough to encode.

In that sense, `fetch-limit` already does a job. It marks a boundary around an engineering question: how do you cap outbound concurrency without turning `fetch` into a heavy abstraction? The interesting part is upstream of the implementation. The code, when it lands, will either confirm that intent or flatten it.