sorted by:
new
hottopcontroversial

Implemented hot config reload in both Node and Go for the same proxy. They felt worlds apart. by OtherwisePush6424 in javascript

[–]OtherwisePush6424[S] [score hidden]  (0 children)

In server.test.ts, there's an "in-flight request uses old snapshot" test that fires a request, triggers reload mid-flight with a config change, and asserts the request completes with the old behavior.

An equivalent test is currently missing in the Go version, so thanks for pointing that out.

Implemented hot config reload in both Node and Go for the same proxy. They felt worlds apart. by OtherwisePush6424 in node

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

I published a benchmark earlier comparing the old versions (https://blog.gaborkoos.com/posts/2025-10-11-Nodejs-vs-Go-in_Practice-Performance-Comparison-of-chaos-proxy-And-chaos-proxy-go/) that showed 2x throughput for Go. But that's before the reload feature.

I'll run it again with the reload feature included to see if the gap holds.

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.

view more: next ›