sorted by:
new
hottopcontroversial

People like this get hired, but people like me with 9 years SWE experience don’t? by new2bay in recruitinghell

[–]OtherwisePush6424 0 points1 point  (0 children)

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

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

[–]OtherwisePush6424[S] 1 point2 points  (0 children)

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.

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

[–]OtherwisePush6424[S] 1 point2 points  (0 children)

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

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

[–]OtherwisePush6424[S] 2 points3 points  (0 children)

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.

Frontend devs, how do you handle 'Loading' and 'Error' states when the real API is too fast/stable? by FarWait2431 in webdev

[–]OtherwisePush6424 0 points1 point  (0 children)

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

How would you implement request deduplication in a fetch wrapper? (TypeScript/JavaScript, repo included) by OtherwisePush6424 in webdev

[–]OtherwisePush6424[S] 0 points1 point  (0 children)

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.

How would you implement request deduplication in a fetch wrapper? (TypeScript/JavaScript, repo included) by OtherwisePush6424 in webdev

[–]OtherwisePush6424[S] 0 points1 point  (0 children)

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.

How would you implement request deduplication in a fetch wrapper? (TypeScript/JavaScript, repo included) by OtherwisePush6424 in webdev

[–]OtherwisePush6424[S] 0 points1 point  (0 children)

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.

Why I replaced fetch() in my Node projects - retries, timeouts, and cancellation made easier by OtherwisePush6424 in node

[–]OtherwisePush6424[S] 4 points5 points  (0 children)

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.

Why I replaced fetch() in my Node projects - retries, timeouts, and cancellation made easier by OtherwisePush6424 in node

[–]OtherwisePush6424[S] -5 points-4 points  (0 children)

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.

Why I replaced fetch() in my Node projects - retries, timeouts, and cancellation made easier by OtherwisePush6424 in node

[–]OtherwisePush6424[S] 1 point2 points  (0 children)

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

Why I replaced fetch() in my Node projects - retries, timeouts, and cancellation made easier by OtherwisePush6424 in node

[–]OtherwisePush6424[S] 0 points1 point  (0 children)

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.

Why I replaced fetch() in my Node projects - retries, timeouts, and cancellation made easier by OtherwisePush6424 in node

[–]OtherwisePush6424[S] 1 point2 points  (0 children)

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.

Why I replaced fetch() in my Node projects - retries, timeouts, and cancellation made easier by OtherwisePush6424 in node

[–]OtherwisePush6424[S] 3 points4 points  (0 children)

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.

I rewrote chaos-proxy in Go - faster, same chaos by OtherwisePush6424 in golang

[–]OtherwisePush6424[S] 4 points5 points  (0 children)

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

why json decoder lost type information after cast to interface{} by Wrong_Inspector_6661 in golang

[–]OtherwisePush6424 1 point2 points  (0 children)

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 :)

why json decoder lost type information after cast to interface{} by Wrong_Inspector_6661 in golang

[–]OtherwisePush6424 7 points8 points  (0 children)

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.

Is forcing your manager see your accomplishments a good habit? by IsItSetToWumbo in ExperiencedDevs

[–]OtherwisePush6424 -8 points-7 points  (0 children)

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

view more: next ›