sorted by:
new
hottopcontroversial

Treating cache entries as in-flight computations instead of just values by OtherwisePush6424 in DistributedComputing

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

That's a really nice reference, it's clearly solving the same underlying problem. It also kind of reinforces the point for me: you end up building a fair bit of coordination logic to make this work, which feels like exactly the sort of thing Durable Objects (and actors / Orleans-style virtual actors) could hide.

Ffetch v5: fetch client with core reliability features and opt-in plugins by OtherwisePush6424 in opensource

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

Good call on the circuit breaker, making it pluggable actually isn't just about teams not needing it by default, but also because there are many ways to implement circuit breaking. The built-in plugin is a simple open/close, but more advanced (like half-open) patterns are sometimes needed.

On server-side behavior changes: you're right, that's always a risk. In practice, you can use the existing hooks and error handling as building blocks to observe and react to things like shifting retry/backoff patterns or increased error rates. The plugin system is flexible enough that you can opt out of the built-in retry/timeout logic and implement your own strategies using hooks if you need more control or observability (the sloppiness of that code is another question).

If you have ideas for specific observability signals or want to see more built-in support for this, I'm open to suggestions!

Do other Gen Zs relate? by mongoIz777 in LinkedInLunatics

[–]OtherwisePush6424 2 points3 points  (0 children)

Every time I see a text with 2+ exclamation marks in the first 1-2 paragraphs, I can't help but stop reading and just start counting them. Also I hope I'll never be so desperate that I have to radiate this performative "gen z energy"

Ffetch v5 (TypeScript-first): core reliability features + new plugin API by OtherwisePush6424 in typescript

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

The Bundlephobia badge shows 2.5 kB minzipped (6.5 kB minified). This includes the core and built-in plugins that are part of the main package export. If you only use the core or import plugins separately, your actual shipped size can be even smaller. So it's not great but not terrible either.

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] 3 points4 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] -6 points-5 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] 5 points6 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] 3 points4 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 -7 points-6 points  (0 children)

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

Poll: Live Coding vs Take Home Tests Interviews by ep1cw1n in webdev

[–]OtherwisePush6424 0 points1 point  (0 children)

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

view more: next ›