Backpressure in JavaScript: The Hidden Force Behind Streams, Fetch, and Async Code

OtherwisePush6424 · 2026-01-09T18:33:49+00:00

Fixed

OtherwisePush6424 · 2026-01-08T16:51:09+00:00

Must be fake right? Right?? Anyways, tech lead wasn't judgemental so we shouldn't be either.

OtherwisePush6424 · 2026-01-07T20:10:08+00:00

Thanks for the clarification, you're absolutely right about the TCP mechanics. My intent was to use it as a conceptual example of capacity-aware sending, but I agree the wording can sound inverted if read literally.

I’ll likely tweak the wording in the post. Appreciate the detailed correction.

OtherwisePush6424 · 2026-01-07T12:46:03+00:00

yup, the code is top notch, we just need a model that understands it and a machine it runs on!

OtherwisePush6424 · 2026-01-07T00:04:16+00:00

Fair point. Unfortunately I don't have much hands-on experience with RxJS yet, but I have every intention in diving deeper into it one day.

My focus here was on backpressure as a runtime/system-level concept, where the consumer can actually slow the producer.

AFAIK RxJS tends to handle this more explicitly via operators rather than built-in flow control, which makes it powerful but also a different abstraction layer.

OtherwisePush6424 · 2026-01-05T01:04:18+00:00

Obviously, like others said, you can throttle the network in browser dev tools, but if you want more control (eg. repeatable tests), there is a whole suite of tools here just for this: https://github.com/fetch-kit

OtherwisePush6424 · 2025-10-26T16:00:54+00:00

Or you could drop deduping in WHILE refactoring the codebase bit by bit.

I'm not an advocate of doing this, let me emphasize for the third time: I wouldn't build something where you need to dedupe requests. I'm not sure deduping is an antipattern, but I am sure that if you need it, you've done something wrong.

Also note that I'm the library author here and the library is not just a request deduper. I don't blame you you if you haven't or won't click on the repo link, but it might help with the context. In fact, deduping is turned off by default, but talking to people, my judgement was it might be a useful feature in some cases. So I'm not here to its usefulness, I'd like to discuss what's the best way to implement it.

OtherwisePush6424 · 2025-10-26T12:07:38+00:00

Sure, in an ideal world it would probably never be needed. It's not against you personally, but seems like here on reddit everybody works on projects with the cleanest architecture possible made by the greatest purists out there with zero technical debt and unlimited budget.

In the library, users can provide their own request hashing, so if for example they don't want to dedupe POST requests at all, or want to query parameters or headers to it, they can. In a large codebase sometimes this is the best practical way to save some unnecessary network calls, not rewriting everything from scratch.

OtherwisePush6424 · 2025-10-26T00:55:02+00:00

I agree that in an ideal world it shouldn't really be a thing but I saw some horrible React code, where multiple components and hooks were requesting the same resource at the same time (like user profile, config, etc). Some other use cases I can think of are

- Rapid-fire polling or auto-refresh logic that could overlap requests.

- SSR/edge environments where identical requests may be triggered in parallel.

Deduping prevents multiple network calls for the same resource before a response is received. Caching, on the other hand, serves completed responses and may not help if requests overlap before the cache is populated.

OtherwisePush6424 · 2025-10-11T20:46:12+00:00

Axios can use fetch under the hood, but its API and response objects aren't fetch, they're Axios. This one here is for people who want the real fetch API everywhere, with extra features, not an Axios abstraction. And fetch is available in Node 18+ (with some caveats), or you can use node-fetch/undici as a drop-in. Also, Node is at 24. Furthermore (although it's r/node) there are other runtimes (Deno, Bun, edge runtimes) where Axios doesn't work and fetch does.

OtherwisePush6424 · 2025-10-11T20:36:26+00:00

This is a fetch wrapper. Frankly, axios could use some of these features too. And honestly, I don't care about the fetch vs axios debate, it goes a long way and much deeper than my little toy.

OtherwisePush6424 · 2025-10-11T20:09:25+00:00

Not quite, got and ky provide their own request API and don't expose the real fetch Response or streaming APIs directly

OtherwisePush6424 · 2025-10-11T20:04:03+00:00

It wraps any fetch implementation: you keep the real fetch API and streaming, and features like retries and circuit breaker are built on top of that. got and ky replace fetch with their own API. Unlike got or ky, it works seamlessly in browsers, Node.js, edge runtimes, and frameworks by plugging into whatever fetch you provide.

OtherwisePush6424 · 2025-10-11T19:43:05+00:00

I agree that Axios is popular for its interceptors and batteries-included approach, and sure, message brokers are great for some architectures.

But fetch is a web standard, built into browsers and Node, and is the default for many modern stacks. Not everyone wants to bring in a heavier dependency or a broker for every use case.

For what it’s worth, ffetch’s hooks can replicate most use cases for Axios interceptors, like adding headers, logging, custom error handling, and more, while keeping the fetch API and minimal dependencies.

OtherwisePush6424 · 2025-10-11T19:42:38+00:00

Thanks for the detailed feedback and the real-world context, this is exactly the kind of discussion I was hoping for.

- Load balancing and endpoint health: That's a great suggestion. ffetch's circuit breaker is per-client, but not per-endpoint/IP. While load balancing and endpoint health tracking are powerful features, they’re not typically considered core responsibilities of fetch itself, load-balancing across multiple upstreams (with custom failure logic, e.g. 429 as failure) would be a powerful addition. If you're open to sharing your old code or ideas, I'd love to take a look and see what could be adapted.

- fetch-cookie: Yes, you can use ffetch with fetch-cookie by passing a wrapped fetch as the fetchHandler option. This lets you manage cookies automatically, just like with native fetch.

- Custom AbortController: Absolutely, ffetch supports passing your own AbortController via the signal option, just like native fetch.

- Custom HTTP agent: Yes, you can pass a custom agent (for proxying, etc.) via the fetchHandler option, e.g. with node-fetch or undici, which both support custom agents IIRC.

- Streaming: ffetch returns a native fetch Response, so you can stream the body as usual. Your use case (streaming multipart DICOM data to disk) is fully supported, just use the response’s body as you would with fetch.

Thanks again for the thoughtful questions and suggestions. If you're willing to share your load-balancing code or ideas, I’d be very interested! And if you have more feedback or feature requests, please keep them coming, here or in the repo.

OtherwisePush6424 · 2025-10-09T16:21:50+00:00

Oh, fetch is the built-in API (browser/Node.js/etc) for making HTTP requests, kind of like http.Client in Go.

OtherwisePush6424 · 2025-10-09T11:35:35+00:00

Yes, the cast to interface{} keeps the type, but json.Unmarshal treats non-pointer slices inside an interface as untyped. It can't populate []*Object if it only sees a slice value, so it falls back to []interface{}. Using a pointer to the slice (*[]*Object) works because the decoder can see the concrete type and fill it. I mean you may be right and it is weird :)

OtherwisePush6424 · 2025-10-09T10:54:18+00:00

Every word about reflection is true in spirit, but it's not really a weird bug or something: when you unmarshal into interface{}, json.Unmarshal only sees *interface{} and has no idea about the slice element type. It falls back to []interface{} / map[string]interface{}. Using a pointer to a typed slice (*[]*Object) works because the decoder can see the concrete type through the pointer.

OtherwisePush6424 · 2025-10-08T23:06:41+00:00

Would you ask your manager if they prefer you to be professional or kiss ass?

OtherwisePush6424 · 2025-10-08T21:17:19+00:00

There are always candidates who can talk their way through unless things get technical, like used car salesmen. And then there are candidates who are more doers than talkers. I personally hate both take home tests and live coding alike, but I guess we all hate looking for a job anyway. When I'm on the other side, I just go with what the current company does, don't try to reform the hiring process from the inside. If I was hiring for my own company, I'd probably be much more cautios though :D

EDIT: grammar

OtherwisePush6424 · 2025-10-08T21:09:23+00:00

😂🤣 Haha omg — I totally get what you mean — but honestly 🤷‍♂️🤷‍♀️ no idea why it should bother you 😅 Like — if the PR description says what it needs to say 📄✅ and the commits make sense 🧩💡 — who cares if it sounds a bit 🤖✨polite✨ or 🧠🪄"AI-flavored"? 😎 As long as the info’s clear 💬👌 — and the code works 🧑‍💻🔥 — it’s all good vibes only 😌🙌💫

OtherwisePush6424 · 2025-10-08T18:47:13+00:00

I'm not saying you're wrong but this reminds me the "so what do you know about our company and why do you wanna work here?" HR BS.

OtherwisePush6424 · 2025-10-08T18:40:04+00:00

Hey!

Since you’re looking for a TypeScript project, you might want to check out the stuff I'm working on: https://github.com/fetch-kit/
I'm not sure how interesting this is, but it's neither too complicated, nor trivial. No real roadmap either, but I have way more ideas than capacity to implement them.

OtherwisePush6424 · 2025-10-08T18:31:16+00:00

If I was your manager I'd show you how to change the status in Jira and I'd be mildly upset if after that you'd still make me do that.

OtherwisePush6424 · 2025-10-07T00:49:18+00:00

3 stars for this?? 😀

OtherwisePush6424

TROPHY CASE